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.

6 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.