# CMake 4.0 regression

**URL:** https://discourse.cmake.org/t/cmake-4-0-regression/13890
**Category:** Development
**Tags:** os:windows
**Created:** [April 6, 2025, 7:05pm UTC](https://discourse.cmake.org/t/cmake-4-0-regression/13890 "2025-04-06T19:05:21Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Gonzalo\_Garramuno](https://discourse.cmake.org/user_avatar/discourse.cmake.org/gonzalo_garramuno/32/265_2.png) [@Gonzalo\_Garramuno](https://discourse.cmake.org/u/Gonzalo_Garramuno)
#### Post date: [April 6, 2025, 7:05pm UTC](https://discourse.cmake.org/t/cmake-4-0-regression/13890/1 "2025-04-06T19:05:21Z")

</div>

CMake 4.0 seems to have introduced a regression on how it treats directories once they have been built with ExternalProject\_Add. Attached is an MSys2 bash script that runs MSVC and compiles three projects. When run once, it works fine. When run again, without clearing the directory, the build fails.  
With CMake 3.29 the build works in both occassions.

[install\_bug.zip](https://discourse.cmake.org/uploads/short-url/xMFlQODhRVXWdpGq8ArRaaKvdlH.zip) (10.1 KB)

---

<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: [April 7, 2025, 9:19pm UTC](https://discourse.cmake.org/t/cmake-4-0-regression/13890/2 "2025-04-07T21:19:20Z")

</div>

Thanks. FYI, you can bump from `libjpeg-turbo` from version `3.0.0` to `3.0.2` or higher to avoid using `CMAKE_POLICY_VERSION_MINIMUM`.

This bisects to my change in [CMake MR 9932](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9932). I’m investigating the cause.

---

<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: [April 8, 2025, 12:28am UTC](https://discourse.cmake.org/t/cmake-4-0-regression/13890/3 "2025-04-08T00:28:56Z")

</div>

The problem was triggered by `cmake/Build/BuildFLTK.cmake` passing `-DCMAKE_C_COMPILER=cl` and `-DCMAKE_CXX_COMPILER=cl` to the `ExternalProject` call to configure FLTK. Every time FLTK re-configures, CMake converts `cl` to the absolute path to `cl.exe`, and compares it to the `CMAKE_{C,CXX}_COMPILER` stored in FLTK’s `CMakeCache.txt`. If the value has changed, CMake assumes the user is trying to reconfigure with a different compiler, and wipes out a bunch of other settings too. This shouldn’t happen in the example’s workflow, but it does with CMake 4.0.0. It triggers on a case-change to `CMAKE_{C,CXX}_COMPILER` because `vcvarsall.bat` sets `PATH` with `.../bin/HostX64/x64` but the actual path on disk is `.../bin/Hostx64/x64` (note the case of `HostX64` versus `Hostx64`).

The comparison is platform-agnostic and case-sensitive. Both sides are supposed to be normalized to their on-disk case before the comparison. However, refactoring in CMake 4.0.0 caused that normalization to be dropped on one side. [CMake MR 10620](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10620) fixes that.