[kamailio/kamailio] cmake: should we use >= 3.13, i.e., "more modern cmake" generation? (Issue #4078)
### Description
From the cmake timeline 3.0(2014) is called "modern cmake" and ~3.12/3.13(2018) is "more modern cmake" : https://www.youtube.com/watch?v=y7ndUhdQuU8
Since we are doing a major renovation on the kamailio build system should we target the "more modern" generation (that is already > 5 years old). This will encourage the project to follow cmake best practices.
Ping @xkaraman @miconda
Versions in debian: buster(3.13) bullseye(3.25) bookworm/trixie(3.30)
Hey @space88man
I opted to used `3.10` as it was a recent enough and available on most platforms (Ubuntu 18.04 offers 3.10).
Now after doing some searching in the `CMakeLists`, I think it's good to upgrade at least to `3.13`.
1. `find_package(LibXml2 REQUIRED)`: To have the target we are using, requires `3.12` as noted in https://cmake.org/cmake/help/latest/module/FindLibXml2.html 2. I make use of this `CMAKE_POLICY`[CMP0079](https://cmake.org/cmake/help/latest/policy/CMP0079.html) introduced in 3.13. This allows me to call `target_link_libraries` with targets defined outside of the current `CMakeLists.txt` 3. I also make use of [CMP0118](https://cmake.org/cmake/help/latest/policy/CMP0118.html#policy:CMP0118), but that is introduced in 3.20. I have the workaround already in place for older versions, so we need no changes on this.
My (optimistic) suggestion: 3.20 seems a reasonable(and low) baseline as that release is about 4 years old.
For older ubuntu/debian: kitware is very good about distributing binaries ; maybe the CI/CD for debian <= 11 and ubuntu <= 20.04 could have a cmake binary from kitware: 3.31.2 is available.
There are probably still a lot of people using Debian Buster with cmake 3.13. As Xenofon mentioned he already provided some workaround for the 3.20, I would suggest to aim for 3.13 support for now.
@henningw Even if that's the case though, `Buster` is EOL since June 2024. Most should upgrade right in the near future?
So, the supported oldest LTS currently offer: - Debian 11 (bullseye) : `3.18` https://packages.debian.org/bullseye/cmake - Ubuntu 20.04 (focal): `3.16` https://launchpad.net/ubuntu/focal/+source/cmake - CentOS 9: `3.20` https://mirror.stream.centos.org/9-stream/AppStream/x86_64/os/Packages/
So, I guess still no `3.20` available for all of the current/oldest LTS releases. `3.13` is a good candidate indeed and maybe `3.16` if we want the most updated supported by all of them.
I think that there are options for extended support for the distros that go beyond the public EoL.Also, some systems run in private networks where the pressure for OS upgrade is very low -- these systems are usually behind an edge proxy/sbc running on a public/private network gateway.
Overall, 4 years old cmake might be insufficient for lot of deployed systems there. If it is not a must (because of severe limitations) to use such recent version, I would rather go for the oldest that is reasonably capable of what is needed for Kamailio, probably 3.10 is ok being shipped with Ubuntu 18.04 (iirc, this was the LTS release still shipping libssl 1.1, not 3.0, and I expect it is still in use quite a lot, not necessary because of Kamailio, but other apps not yet coping well with libssl 3.x).
The alternative is to keep the old-makefiles for another devel cycle or so. In this case, cmake can be set to a newer version, to make it more modern for recent distros and the future.
I haven't tried it, but my guess is that `3.13` would be needed due to policy I used. I don't think there is an easy workaround for that. As @space88man `cmake` provides good alternatives on how to install newer versions, at least on Ubuntu and probably Debian!
Small clarification - the 3.13 is from 2018, so its already 6 years old. The 4 year old was the cmake 3.20. If one really still needs to use a Ubuntu 18.04. there are the options to install cmake with binary packages, or with the special ubuntu method of "snap": https://cmake.org/download/#binary
As Ubuntu 18.04 is end of life since May 2023, this will probably not affect many people.
This seems to be really easy to be installed even on ubuntu 16.04 according to the package provider https://snapcraft.io/install/cmake/ubuntu
As Ubuntu 18.04 is end of life since May 2023, this will probably not affect many people.
The paid subscription, which many large enterprises/carriers pay for, offers extended support till 2028:
- https://ubuntu.com/blog/18-04-end-of-standard-support
On some deployments there are constraints due to legal requirements (e.g., banks), to use only the "certified" distro packages.
I just tested installing cmake 3.31.2 as a binary and compiling it from source on a system that has only cmake 2.18.12. https://cmake.org/download/
With both methods kamailio compiled successfully. Note: it takes quite a while to compile cmake from source.
On Wed, Dec 18, 2024 at 10:30 AM Daniel-Constantin Mierla via sr-dev sr-dev@lists.kamailio.org wrote:
As Ubuntu 18.04 is end of life since May 2023, this will probably not affect many people.
The paid subscription, which many large enterprises/carriers pay for, offers extended support till 2028:
https://ubuntu.com/blog/18-04-end-of-standard-support
On some deployments there are constraints due to legal requirements (e.g., banks), to use only the "certified" distro packages.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: kamailio/kamailio/issues/4078/2551614001@github.com
Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org To unsubscribe send an email to sr-dev-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
As Ubuntu 18.04 is end of life since May 2023, this will probably not affect many people.
The paid subscription, which many large enterprises/carriers pay for, offers extended support till 2028:
* https://ubuntu.com/blog/18-04-end-of-standard-supportOn some deployments there are constraints due to legal requirements (e.g., banks), to use only the "certified" distro packages.
Sure. But if such a legal requirements exists, I am wondering how they will use Kamailio then on their platform. We are not providing this officially certified packages either. And if they build Kamailio by themself, why they also not could also add some build dependencies as well.
The kamailio 5.8 branch will be maintained for another year, so its also not that people need to switch immediately.
deb packages will be generated only with official repositories, period. If any distribution/release has an ancient cmake version, I will drop support for it.
Good point, cmake 3.13 would mean drop support for 18.04, cmake 3.10 would mean drop support for 16.04. Both are currently packaged on deb.kamailio.org.
We should probably formalize some support timeline (e.g. on a web page) also for distributions. Xenofon will list again the issues we would have going back to 3.10, right now the requirement is 3.13 as I understand it.
@linuxmaniac: would it be ok (ie., not add too much complexity) if we also keep old-makefiles, so for older distros they are used for building (the deb specs for them should be there, right, no extra work) and for newer distros cmake is used? In this way, we can bump cmake to a more recent version that meets all that is needed/wanted, and still support older distros.
@ovidiusas: in the past, you used to do cross-compiling. Are you still doing it? If yes, is the new cmake build system supporting/impacting it?
Sure. But if such a legal requirements exists, I am wondering how they will use Kamailio then on their platform. We are not providing this officially certified packages either. And if they build Kamailio by themself, why they also not could also add some build dependencies as well.
Compiling a specific app from sources usually gets reviewed and approved if that system is designated for running it. But changing the default build tools and other packaged libs are hardly accepted because they affect the entire system and they are more security sensitive than a single app.
@ovidiusas: in the past, you used to do cross-compiling. Are you still doing it? If yes, is the new cmake build system supporting/impacting it?
I used to cross-compile for optware. I no longer have a toolchain to test it.
For cmake this should be much less of a (security) concern as it is a build-system generator only: it does not change the distro build tools, viz., make / gcc / binutils - which are used during the actual build.
Users buster/16.04/18.04 can use 3.31 from kitware - the generated Makefiles can be vetted. One advantage of cmake is that the output directory is outside the source tree which can be mounted read-only!
Compiling a specific app from sources usually gets reviewed and approved if that system is designated for running it. But changing the default build tools and other packaged libs are hardly accepted because they affect the entire system and they are more security sensitive than a single app.
For cmake this should be much less of a (security) concern as it is a build-system generator only: it does not change the distro build tools, viz., make / gcc / binutils - which are used during the actual build.
It doesn't change them if it is not compromised, the tools in the build chain are very sensitive from security point of view -- they can create files, change the code, ...
Makes no sense to focus anymore on whether is possible to get or not newer build tools on the old distros, but decide what is the oldest cmake that can be reasonably used, and keep the old makefiles for the distros that don't have it.
@xkaraman looked to the cmake 3.10 and also did some tests. He need to change many modules again if we want to go back to 3.10 which is quite an effort. He never supported 3.10, all his tests were done with 3.13. So unless we want to spend more time on that, the usable cmake version is 3.13 from ubuntu 20.04.
If we keep both cmake and old Makefiles, we need to maintain now both, which is more work as before. So we probably should decide when we finally can get rid of this old Makefiles, e.g. for release 6.1? This mean we could remove them after the branch has been created and there would be minimal additional effort.
My goal is also to have the least work done, therefore I think the compromise with using old-makefiles for old distros is a good choice.
By keeping the old-makefiles does not mean to develop them further (eg., when a new compiler version comes out, old-makefiles will not be updated, only cmake stuff (if needed)). We can even move them to a separate folder (e.g., `misc/makefiles/`) so they are not interfering at all with the future development and have a shell script (or a make in the root folder) to copy over the source tree when needed (e.g., for old-distros). Eventually, for some time, on new modules we need to add a new Makefile, but that is not a big overhead.
Bottom line, I would rather have a simpler cmake system that is oriented to to future, rather than making it complex now to cope with the past, and let the past be handled by existing makefiles.
ITNOA
@miconda if I understand correctly, you want to use cmake for new version, and in modern distro cmake 3.20 is installed, so why does not upgrade cmake to 3.20?
Please lets not start this discussion again. We decided that the minimum cmake version for now is 3.10. This was commited in ad35c24196c9.
Closed #4078 as completed.
Please lets not start this discussion again. We decided that the minimum cmake version for now is 3.10. This was commited in [ad35c24](https://github.com/kamailio/kamailio/commit/ad35c24196c921a3e870f4a48b6d2867...).
Just to correct my wrong statement from some weeks ago. It was discussed that the minimum cmake version will be 3.13 ([link](https://github.com/kamailio/kamailio/issues/4078#issuecomment-2553148148)). Thanks @xkaraman for pointing this out to me.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Ovidiu Sas -
Ovidiu Sas
-
soroshsabz
-
space88man
-
Victor Seva
-
Xenofon Karamanos