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:
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.
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.
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?