Expected fallout of CMake-based projects from CMake 4.0?

Development
1

CMake 4.0 is going to introduce some degree of backward incompatibility. This will lead to fallout of CMake-based projects.

Is there any attempt to figure out how many and which projects are effected? Something like a package mass rebuild with CMake 4.0 rc3 for Fedora, Debian, or OpenSuse would reveal where we can warn our users in the open source world.

1 Like
2

Debian issue 1098837 tracks packaging CMake 4.0 and has some discussion of the number of packages affected.

FWIW, CMake has been issuing warnings about the pending compatibility removal for several years. Any project that was updated to avoid those warnings will not have a problem with CMake 4.0. For packagers we offer CMAKE_POLICY_VERSION_MINIMUM to help with projects that haven’t been updated.

7 Likes
3

openSuse has set up a tracker bug to track all current CMake 4 related build failure bugs, see 1239788 – cmake4: build failure tracker bug..

All packages are build with CMake 4.0-rc4, the current status can be found in https://build.opensuse.org/project/show/home:simotek:cmake4.
E.g., openSuse Tumbleweed on x86_64 has 355 packages that fails to build; not every failure is necessarily connected to the use of CMake 4.0.

4

I perused the first page of failed results from i586 after sorting and have so far only seen things that would be resolved with CMAKE_POLICY_VERSION_MINIMUM and one instance of a “32bit not supported” compile assertion. Would you be able to rerun the failed packages with that variable set?

5

vcpkg PR to update to CMake4: [vcpkg-scripts] Update to CMake 4.0.0-rc4 by Neumann-A · Pull Request #44273 · microsoft/vcpkg · GitHub

Observed problems:

  • old policy settings (a switch to simply ignore the errors would be nice)
  • Main mac problem: Clang vs AppleClang (It really did not help to have a policy for this which now gets thrown out the window, i don’t see why this one even gets removed.)
  • CMAKE_OSX_SYSROOT being empty, breaking e.g. LLVM (feels like a hack to use _CMAKE_OSX_SYSROOT_PATH instead.)
6

Hi,
Currently its doing a rebuild, and I saw a bunch of unrelated failures but https://build.opensuse.org/project/show/home:simotek:cmake4b has that list generally looking at x86_64 is probably best.

I also made the change by adding -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to our main cmake macro, because it was the simplest method I could think of which means that packages that call cmake directly rather then using the macro will probably still fail with the version error.

1 Like
7

Indeed, a quick scan seems to show that is the case. Note that it is also an environment variable if that helps.

8

Sorry for the slow reply, I don’t think it will not without having to modify each spec file manually, I guess the other question is as a Linux distro which will be auto rebuilding all cmake packages is it likely to break or cause issues by setting -DCMAKE_POLICY_VERSION_MINIMUM=3.5 as the default behavior.

9

Has there been a new mass rebuild since then? Any news to report on the Debian CMake 4.0 deployment?

10

I can only report for openSUSE:

  1. CMake 4.0 is still not part of the main projects Leap, Tumbleweed, and Slowroll.
  2. We are still tracking the number of failing packages. It started with more then 120 build failures and is now somewhere at 80.
  3. The number is inflated by build failures caused by moving to GCC 15 (C23 by default, more strict includes required for C++) without having a full rebuild of all packages.
  4. So far I am not aware of any issue that is caused by CMake 4.0. Just the intended behavior changes like stop working with minimum required CMake version of below 3.5 and removed old policy behavior.
1 Like