RFC 8 - source code release with cmake

# 5 years ago
Andy	Dear All, the time has come to make a new source code release (from GitHub) and we are thinking of moving from autotools to cmake for the source code release. Does anyone have any thoughts about this, experience, tips, etc. they would like to share? The advantages we see of cmake are: 1. same build system as for source code in repositories 2. supports building binary packages on many systems including Windows 3. simpler than autotools (we hope) We would appreciate to get your comments and feedback. Andy, Reynald and Ireneusz

# 5 years ago

Dear All,

the time has come to make a new source code release (from GitHub) and we are thinking of moving from autotools to cmake for the source code release.

Does anyone have any thoughts about this, experience, tips, etc. they would like to share?

The advantages we see of cmake are:

1. same build system as for source code in repositories
2. supports building binary packages on many systems including Windows
3. simpler than autotools (we hope)

We would appreciate to get your comments and feedback.

Andy, Reynald and Ireneusz

# 5 years ago
t-b	I definilty favour the move to cmake. It is much more modern than autotools. In addition with cmake you can use tools like clang-tidy.

# 5 years ago
claudio	Yes, it is a good idea. I would try not to use the features of too recent version of cmake: we have some old system supporting cmake 2.4.

# 5 years ago
Reynald	I understand your concern Claudio. Please note that it's quite easy to install a more recent version of CMake on old operating systems. I managed to install very easily CMake 3.0.2 on one of our old Redhat Enterprise 4 machines (gcc 3.4.6). This is what we did for cppTango automated tests on Debian 7 too. On Travis machines, we install manually CMake 3.10 using the following commands, for instance: `wget –no-check-certificate https://cmake.org/files/v3.10/cmake-3.10.0-Linux-x86_64.sh -O /tmp/cmake-install.sh chmod +x /tmp/cmake-install.sh /tmp/cmake-install.sh –skip-license –exclude-subdir` You can also use some special options of the installer script to install CMake manually in a folder of your choice. This can work even if you don't have admin permissions if you install it in a folder where you have write permissions. If you need a 32 bits version, you will have to use some older versions, but CMake website is providing installers for Linux 32 bits for CMake 3.6 for instance (https://cmake.org/files/v3.6/). So I think we should not impose support for a version as old as CMake 2.4 when many interesting features were introduced in CMake 3.0. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago

Reynald

I understand your concern Claudio.

Please note that it's quite easy to install a more recent version of CMake on old operating systems.
I managed to install very easily CMake 3.0.2 on one of our old Redhat Enterprise 4 machines (gcc 3.4.6).
This is what we did for cppTango automated tests on Debian 7 too.
On Travis machines, we install manually CMake 3.10 using the following commands, for instance:

wget –no-check-certificate https://cmake.org/files/v3.10/cmake-3.10.0-Linux-x86_64.sh -O /tmp/cmake-install.sh
chmod +x /tmp/cmake-install.sh
/tmp/cmake-install.sh –skip-license –exclude-subdir

You can also use some special options of the installer script to install CMake manually in a folder of your choice. This can work even if you don't have admin permissions if you install it in a folder where you have write permissions.

If you need a 32 bits version, you will have to use some older versions, but CMake website is providing installers for Linux 32 bits for CMake 3.6 for instance (https://cmake.org/files/v3.6/).

So I think we should not impose support for a version as old as CMake 2.4 when many interesting features were introduced in CMake 3.0.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 5 years ago
t-b	Cmake 2.4 is way too ancient to use.

# 5 years ago
picca	Hello, for packaging it is important to use the gnuinstalldirs. This is way it is really simple to customize standards path. Just for info will you use cmake + make, cmake + ninja, or whatever. Another build system seems to have "le vent en poupe" meson[1]. It seems that the Gnome project are migrating more and more of it's projects from autotools to meson. It is already supported in the Debian packaging, so this is not a showstopper for the packaging. systemd already migrate also, so It seems to me that on the long run meson is a serious contender. what about doing a test with both in order to check what is simple or harder to do with both build systems. Cheers Frederic [1] http://mesonbuild.com/index.html

# 5 years ago

picca

Hello, for packaging it is important to use the gnuinstalldirs. This is way it is really simple to customize standards path.

Just for info will you use cmake + make, cmake + ninja, or whatever.

Another build system seems to have "le vent en poupe" meson[1]. It seems that the Gnome project are migrating more and more of it's projects from autotools to meson. It is already supported in the Debian packaging, so this is not a showstopper for the packaging. systemd already migrate also, so It seems to me that on the long run meson is a serious contender.

what about doing a test with both in order to check what is simple or harder to do with both build systems.

Cheers

Frederic

[1] http://mesonbuild.com/index.html

# 5 years ago
Reynald	Hi Frédéric, Thanks for your input. The idea was to simply use CMake (+ make). I must say I am not familiar with ninja and meson. Thanks for the link. As I said, we should try to avoid to use too old versions of CMake. On the other hand, we need to ensure we can still install tango 9 and the main tools on some (very?) old operating systems too. Can we do that with meson? Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago

Reynald

Hi Frédéric,

Thanks for your input.
The idea was to simply use CMake (+ make).
I must say I am not familiar with ninja and meson. Thanks for the link.
As I said, we should try to avoid to use too old versions of CMake.
On the other hand, we need to ensure we can still install tango 9 and the main tools on some (very?) old operating systems too.
Can we do that with meson?

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 5 years ago
picca	Here the dependencies of meson and ninja-build https://packages.debian.org/sid/meson https:http://packages.debian.org/sid/ninja-build http://mesonbuild.com/Quick-guide.html Cheers

# 5 years ago
t-b	https://cmake.org has a much longer list of reference projects. And especially clang/llvm are using cmake as well. And interesting read is also at https://www.reddit.com/r/programming/comments/6tsshp/gtk_drops_autotools_in_favor_of_meson/.

# 5 years ago
picca	Hello, just to be clear, the only important point for me is: - the buildsystem MUST be supported by distributions tools. (Debian, Fedora, Arch, guix, nix, etc…). - cross compilation of tango (important for plenty of small arm devices IOT, etc…) - add a test suite which could be use to test that tango is working :). Cheers Fred