cmake-init
cmake-init copied to clipboard
cginternals
Upgrade minimum required CMake version
Time passed and we should discuss the currently minimum required version of cmake-init. @Tachi107 argues that 3.5 is a feasible alternative (https://github.com/cginternals/cmake-init/issues/112).
Maybe we can and should go even higher. CMake has had a lot of interesting improvements in it's later versions, superseding some of our own implementations.
At least, we should get rid of the compatibility layer source code.
I'm fine with updating. I'm not on track with new versions of cmake, but in general, I prefer supporting relatively current versions and not trying to keep compatibility with old versions too long. So, let's update :)
Il giorno dom 5 feb 2023 alle 13:57:08 -08:00:00, Willy Scheibel @.***> ha scritto:
Maybe we can and should go even higher. CMake has had a lot of interesting improvements in it's later versions, superseding some of our own implementations.
Hi, thank you for your replies. Yes, I'd suggest requiring something even newer; if you really want to compile new projects on old systems, you can always get a newer CMake by downloading precompiled binaries or by compiling it yourself.
For the record, the latest Debian release, to be soon replaced by the upcoming Debian 12 release, ships version 3.18.
Some months ago I looked into adopting (i.e. become the new maintainer of) the glbinding Debian package which is still stuck at version 2.1.1, but gave up. The CMake build script is overly complicated, and patching it to better conform to Debian's policies is extremely hard.
Upgrading the minimum required CMake version would help to mitigate some issues, but it'd also necessary to drop some custom code and use the traditional CMake interfaces (for example, it'd be nice to start using the GNUInstallDirs module instead of manually handling install directories).
-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
When upgrading the minimum required CMake version, we can also work on those issues:
- #103
- #108
- #112
- #113
- https://github.com/cginternals/glbinding/issues/285
- https://github.com/cginternals/glbinding/issues/333
- https://github.com/cginternals/cppfs/issues/24
A quick summary of available CMake versions by OS / distribution and distribution channel:
- macOS / Homebrew: CMake 3.25
- macOS / MacPorts: CMake 3.24
- Windows / nuget: CMake 3.15
- Windows / chocolatey: CMake 3.25
- Debian / apt: CMake 3.18
- Ubuntu / apt: CMake 3.22
- Ubuntu / snap: CMake 3.25
As far as I collected data, our main major platforms and major distribution channels allow for a CMake version of 3.15 or higher. If we ignore the out-of-date package in nuget, it's CMake 3.18 or higher. And as @Tachi107 mentioned, there's always the possibility to grab a pre-built version of CMake or build it from source yourself (https://cmake.org/download/).
I think we can create different branches for different CMake versions. This approach allows users to maintain separate code bases that are compatible with specific CMake versions. By doing so, users who require a lower CMake version can use the appropriate branch while others can work with the latest version.
Il giorno ven 19 mag 2023 alle 04:59:35 -07:00:00, aiyolo @.***> ha scritto:
I think we can create different branches for different CMake versions. This approach allows users to maintain separate code bases that are compatible with specific CMake versions. By doing so, users who require a lower CMake version can use the appropriate branch while others can work with the latest version.
That sounds to me like a too complex solution... Realistically nobody needs to use e.g CMake 3.7 in 2023
According to https://lists.debian.org/debian-devel/2023/06/msg00150.html, CMake 3.27 will begin issuing deprecation warning if projects declare a cmake_minimum_required() version lower than 3.5.
This is a clear indication from the CMake devs that yes, we should bump the minimum required version.