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 (10.1 KB)
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. I’m investigating the cause.
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 fixes that.