# MAKE\_TERMOUT environment variable causes a number of CMake generated variables to not be set correctly
**URL:** https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104
**Category:** Usage
**Tags:** gen:makefiles
**Created:** [August 22, 2025, 9:00pm UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104 "2025-08-22T21:00:39Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Amguls](https://discourse.cmake.org/u/Amguls)
#### Post date: [August 22, 2025, 9:00pm UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104/1 "2025-08-22T21:00:39Z")
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`:
```auto
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:
```auto
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](https://gitlab.kitware.com/cmake/cmake/-/commit/509c4244724beab59f72d7b019e7bccd070191ff) - prior to this the environment variable did not appear to have this effect.
From [Special Variables (GNU make)](https://www.gnu.org/software/make/manual/html_node/Special-Variables.html)
> If you invoke a sub-`make` and 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?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 23, 2025, 1:54am UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104/2 "2025-08-23T01:54:45Z")
I can’t comment on the main topic of your post, but the example `CMakeLists.txt` file you’re generating is invalid. It needs a `project()` call after `cmake_minimum_required()`. See if the behavior changes after you fix that.
---
### Author:  [@Amguls](https://discourse.cmake.org/u/Amguls)
#### Post date: [August 23, 2025, 6:20am UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104/3 "2025-08-23T06:20:42Z")
Thanks for pointing that out. It doesn’t make a difference to the behaviour I’m seeing - I just went a little too far in trying to make a minimal example.
In practice I observed this since I was invoking a library’s CMake via a Makefile recipe and, while it worked using CMake 3.28, when I tried using CMake 4.1.0 it started failing to find zlib. Some further investigation led to finding this particular environment variable appearing to be the cause.
A more complete example `CMakeLists.txt`
```auto
cmake_minimum_required(VERSION 3.28)
project(Example)
find_package(ZLIB REQUIRED)
```
With the `MAKE_TERMOUT` variable set to non-empty value, 3.28 output contains:
```auto
Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.3")
```
whereas 4.1 output contains:
```auto
Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.3")
```
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 23, 2025, 7:49am UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104/4 "2025-08-23T07:49:17Z")
Ok, that’s a much better example. Could you please open a new bug report in our issue tracker for this, and include that last example with the description. This sounds like a regression in one of the recent releases.
[https://gitlab.kitware.com/cmake/cmake/-/issues/new](https://gitlab.kitware.com/cmake/cmake/-/issues/new)
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [August 25, 2025, 3:28pm UTC](https://discourse.cmake.org/t/make-termout-environment-variable-causes-a-number-of-cmake-generated-variables-to-not-be-set-correctly/15104/5 "2025-08-25T15:28:56Z")
I suspect this was caused by the same problem fixed by [CMake MR 11080](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11080).