# Expected fallout of CMake-based projects from CMake 4.0?

**URL:** https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689
**Category:** Development
**Created:** [March 5, 2025, 9:38pm UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689 "2025-03-05T21:38:07Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![gruenich](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/977dab/32.png) [@gruenich](https://discourse.cmake.org/u/gruenich)
#### Post date: [March 5, 2025, 9:38pm UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/1 "2025-03-05T21:38:07Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 5, 2025, 9:51pm UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/2 "2025-03-05T21:51:38Z")

</div>

[Debian issue 1098837](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098837#10) 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`](https://cmake.org/cmake/help/v4.0/envvar/CMAKE_POLICY_VERSION_MINIMUM.html) to help with projects that haven’t been updated.

---

<div class="post-metadata">

### Author: ![gruenich](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/977dab/32.png) [@gruenich](https://discourse.cmake.org/u/gruenich)
#### Post date: [March 21, 2025, 3:10pm UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/3 "2025-03-21T15:10:16Z")

</div>

openSuse has set up a tracker bug to track all current CMake 4 related build failure bugs, see [1239788 – cmake4: build failure tracker bug.](https://bugzilla.opensuse.org/show_bug.cgi?id=1239788).

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](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.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 21, 2025, 3:42pm UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/4 "2025-03-21T15:42:12Z")

</div>

> [@gruenich](#):
>
> 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](https://build.opensuse.org/project/show/home:simotek:cmake4).

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?

---

<div class="post-metadata">

### Author: ![Neumann-A](https://discourse.cmake.org/user_avatar/discourse.cmake.org/neumann-a/32/1647_2.png) [@Neumann-A](https://discourse.cmake.org/u/Neumann-A)
#### Post date: [March 23, 2025, 9:45am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/5 "2025-03-23T09:45:15Z")

</div>

vcpkg PR to update to CMake4: [[vcpkg-scripts] Update to CMake 4.0.0-rc4 by Neumann-A · Pull Request #44273 · microsoft/vcpkg · GitHub](https://github.com/microsoft/vcpkg/pull/44273)

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

---

<div class="post-metadata">

### Author: ![simotek](https://discourse.cmake.org/user_avatar/discourse.cmake.org/simotek/32/5448_2.png) [@simotek](https://discourse.cmake.org/u/simotek)
#### Post date: [March 26, 2025, 12:35am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/6 "2025-03-26T00:35:33Z")

</div>

Hi,  
Currently its doing a rebuild, and I saw a bunch of unrelated failures but [https://build.opensuse.org/project/show/home:simotek:cmake4b](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.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 26, 2025, 11:53am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/7 "2025-03-26T11:53:52Z")

</div>

> [@simotek](#):
>
> 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.

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

---

<div class="post-metadata">

### Author: ![simotek](https://discourse.cmake.org/user_avatar/discourse.cmake.org/simotek/32/5448_2.png) [@simotek](https://discourse.cmake.org/u/simotek)
#### Post date: [April 16, 2025, 8:20am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/8 "2025-04-16T08:20:07Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 20, 2025, 2:40am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/9 "2025-07-20T02:40:25Z")

</div>

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

---

<div class="post-metadata">

### Author: ![gruenich](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/977dab/32.png) [@gruenich](https://discourse.cmake.org/u/gruenich)
#### Post date: [July 20, 2025, 7:21am UTC](https://discourse.cmake.org/t/expected-fallout-of-cmake-based-projects-from-cmake-4-0/13689/10 "2025-07-20T07:21:46Z")

</div>

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](https://build.opensuse.org/project/show/home:simotek:cmake4b). 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.
