When using the Unix Makefiles generator, if the MAKE_TERMOUT environment variable is set to a non-empty value at CMake generation time (for example, if invoking cmake from a Makefile recipe), many CMake variables are not resolved correctly. This leads to CMake failing to be able to find some libraries (eg. zlib on Ubuntu).
Using CMake 4.1.0 from snap on Ubuntu 24.04 as an example environment, and focusing on CMAKE_LIBRARY_ARCHITECTURE:
echo "cmake_minimum_required(VERSION 4.0)" > CMakeLists.txt
mkdir build{1,2}
cmake -G"Unix Makefiles" -B build1
MAKE_TERMOUT="anything" cmake -G"Unix Makefiles" -B build2
grep -r CMAKE_LIBRARY_ARCHITECTURE
Output:
build1/CMakeFiles/4.1.0/CMakeCCompiler.cmake: set(CMAKE_LIBRARY_ARCHITECTURE "x86_64-linux-gnu")
build1/CMakeFiles/4.1.0/CMakeCXXCompiler.cmake: set(CMAKE_LIBRARY_ARCHITECTURE "x86_64-linux-gnu")
build2/CMakeFiles/4.1.0/CMakeCCompiler.cmake: set(CMAKE_LIBRARY_ARCHITECTURE "")
build2/CMakeFiles/4.1.0/CMakeCXXCompiler.cmake: set(CMAKE_LIBRARY_ARCHITECTURE "")
Many other CMAKE_* variables are also set as empty or with default/incorrect values - diff -r build1 build2 shows many such cases.
By bisecting, I found this behaviour appears to have been introduced by StdIo: Replace uses of KWSys Terminal with StdIo::Print (509c4244) · Commits · CMake / CMake · GitLab - prior to this the environment variable did not appear to have this effect.
From Special Variables (GNU make)
If you invoke a sub-
makeand redirect its stdout or stderr it is your responsibility to reset or unexport these variables as well, if your makefiles rely on them.
Is it the responsibility of the CMake caller to handle this variable with something like env -u and the previous behaviour was not necessarily supported, or should CMake be responsible for this internally and this is a bug?