Hi folks,
We last increased the minimum CMake version from 3.13.4 to 3.20 in June 2023 after this RFC in October 2022. Now’s the time to do that again. This proposal proposes requiring CMake 3.28.3 or more recent for LLVM 23, see the rationale below.
The primary motivation is that libc++ needs to start building its dylib with support for C++26 language features, and the easiest way to do that is to set the C++ Standard via e.g. CXX_STANDARD 26, as shown in this PR. That requires a newer CMake than our current minimum. It’s also a good idea, generally speaking, to keep the minimum CMake version reasonably up to date for good build system hygiene. Based on the last RFC, I think that is pretty uncontroversial.
Our general RFC process for these updates usually focuses around selecting the minimum version based on the current LTS releases of Linux, so I’ll do that below (based on a mix of this table and asking Google):
| LTS Release | Default CMake version |
|---|---|
| CentOS Stream 9 | 3.31.8 |
| CentOS Stream 10 | 3.31.8 |
| Debian 11 | 3.18.4 |
| Debian 12 | 3.25.1 |
| Debian 13 | 3.31.6 |
| Debian 14 | 4.2.3 |
| Ubuntu 20.04 LTS | 3.16.3 |
| Ubuntu 22.04 LTS | 3.22.1 |
| Ubuntu 24.04 LTS | 3.28.3 |
| FreeBSD 13-STABLE | 3.31.10 |
| FreeBSD 14-STABLE | 3.31.10 |
| NetBSD 9.x | 3.16.1 |
| NetBSD 10.x | 4.1.1 (not certain?) |
Most (if not all) distributions support updating to newer versions of CMake by downloading a binary package.
Based on the table above, I think that CMake 3.28.3 is a reasonable requirement, and it meets the requirements for libc++.
The proposed update process is based on what we did last time:
- Immediately: Issue a CMake warning when the version is less than 3.28.3.
- Immediately: Notify all build bot owners.
- Two weeks after the warning: Make the warning into an error, iterate on fixing broken build bots (likely reverting back to a warning and trying again until everything works).
- Once the error sticks (and so all bots have been updated), send a message indicating the end of the migration.
This proposal intentionally uses an aggressive timeline for upgrading from a warning to an error: my experience is that nobody sees warnings, so adding a warning is close to doing nothing. Leaving a lot of time between the warning and the error is, IMO, just wasting time that could be spent actually pushing the migration forward. I also want to prevent the effort from lingering for too long since I know I won’t have bandwidth to push this for months.
Thoughts welcome!
Louis