What has changed since the previous RFC is that every current LTS release of a major supported OS now provides at least CMake 3.31.
LTS Release
Default CMake version
CentOS Stream 9
3.31.8
CentOS Stream 10
3.31.8
Debian 13
3.31.6
Debian 14
4.2.3
Ubuntu 24.04 LTS
3.28.3
Ubuntu 26.04 LTS
4.2.3
FreeBSD 14-STABLE
3.31.10
FreeBSD 15-STABLE
3.31.10
NetBSD 9.x
3.16.1
NetBSD 10.x
4.2.3
Most distributions also support updating to newer versions of CMake by downloading a binary package. Kitware maintains an APT repository which provides the latest binaries for Ubuntu 24.04, 22.04 and 20.04.
The motivation for updating the minimum version is primarily new features. The following is just a subset of features introduced between CMake 3.21 and 3.31 which I’d like to utilize to simplify the LLVM build (in no particular order):
Expanded support for generator expressions in more contexts.
First-class support for headers and modules.
Significantly improved support for linker feature and flag handling.
Improved management of scopes with the block() and return() commands.
Thanks for picking this up @petrhosek ! I am, unsurprisingly, strongly in favour of doing this. It’s good hygiene and will unblock simplifications in the build system.
+1 to this. I maintain an internal cmake-based project that is used by a downstream LLVM repository. Our internal infrastructure used by this long ago moved to a much more recent version (at least 3.31, I forget whether it’s moved to 4.x yet), but the LLVM-based repository lags behind because of the required upstream CMake version, if I’m not mistaken. As a consequence, my internal project still has to support older CMake versions, even though we never build it with such. A more recent version of CMake in LLVM would allow us to bump our internally officially supported version to what we actually support in practice.
The main reason why we might want to support old cmake versions is to ensure that first-time contributors are able to build LLVM out-of-the box on a variety of reasonably recent distributions. The only thing that gives me pause is that Ubuntu 24.04 LTS is on cmake 3.28.1 and 26.04 is not yet six months old. I wish we had some clear policy about what LTS distros we aim to support in general, but that’s a separate discussion. 26.04 seems “old enough” that it’s reasonable to ask 24.04 users to install cmake separately outside the system package manager (homebrew, conan, container, whatever).
One of the other concerns that comes up here is building LLVM to target old environments, and for those use cases, you can build LLVM in a modern environment, using a legacy sysroot. CMake supports that, you don’t have to build on the old system to target the old system.