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:CMP…, but that is introduced in 3.20. I have the workaround already in place for older versions, so we need no changes on this. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551059295 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551059295(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551309205 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551309205(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551554793 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551554793(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551586534 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551586534(a)github.com>

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 or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551614001 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551614001(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551635755 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551635755(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2551827134 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4078/2551827134(a)github.com>

@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? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2552030175 You are receiving this because you commented. Message ID: <kamailio/kamailio/issues/4078/2552030175(a)github.com>

I used to cross-compile for optware. I no longer have a toolchain to test it. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2552271145 You are receiving this because you commented. Message ID: <kamailio/kamailio/issues/4078/2552271145(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2553128929 You are receiving this because you commented. Message ID: <kamailio/kamailio/issues/4078/2553128929(a)github.com>

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. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4078#issuecomment-2553528069 You are receiving this because you commented. Message ID: <kamailio/kamailio/issues/4078/2553528069(a)github.com>