Specifying uncached compile-time constants in CMakeLists file

Question

In one of my CMakeList files I specified an option which conditionally defines a compile-time constant in a generated header file. However, I recognized that the value of the option is being cached by cmake.

This leads to the unintentional behaviour that I need to delete the cmake cache everytime I change the option and issue cmake .. Currently this is the only option being used. Later on I would like to use more options.

It is really confusing to me that the CMakeLists.txt does not represent the actual build setting due to the caching mechanism. E.g. an build flag set in the CMakeLists.txt but still unset in the cache.

I don't want to disable caching, I just want that my build is always in sync with the build flag set in the CMakeLists.txt. I understand that cmake's caching mechanism is saving lot of time during large builds. Which is actually good.

Does there exist some means to force an option to be up-to-date on cmake .?

I tried to turn the option into a set instruction. The cmake still uses the cached value instead of the actual one.

What am I doing wrong?

Here is my CMakeLists.txt:

cmake_minimum_required(VERSION 3.10)
project(Test VERSION 1.0)
option(MY_BUILD_FLAG "bla" OFF)
configure_file(TestConfig.h.in TestConfig.h)

Here is my change which I unsuccessfully tried out:

cmake_minimum_required(VERSION 3.10)
project(Test VERSION 1.0)
# Here you can set several build flags ON or OFF
set(MY_BUILD_FLAG "bla" OFF)
configure_file(TestConfig.h.in TestConfig.h)

I don't understand your question. What is the actual behavior you observe and what is the behavior your expect? — Alex Reinking, Aug 31 '22 at 15:21
The option value set in the CMakeLists.txt is different from the value used in the generated header file. I'm searching for a mechanism to force the value to be current. The cache still holds an old value. I understand the sense of the cache. However when testing different configurations it is very cumbersome to always delete the cache before issuing `cmake .`. For the final build it would be ok to me to define some default value for the cache but not during experimentation and testing phase. There must be a way to set a value directly instead of setting a default. — Wör Du Schnaffzig, Aug 31 '22 at 15:48
`option()` and `set(CACHE)` commands are used for values, **modifiable by a user**. Command `set(CACHE ... INTERNAL)` is used for values which require **long computation** and one want to cache them. If your purpose is neither of described above, then do not use these commands and use plain `set` instead. — Tsyvarev, Aug 31 '22 at 16:00

score 0 · Answer 1 · answered Aug 31 '22 at 17:51

I understand that cmake's caching mechanism is saving lot of time during large builds.

This is incorrect. The purpose of cmake cache variables is to persist variables across information for subsequent reconfigurations of the same build directory.

The fact that e.g. .o files remain in the build directory unless explicitly cleared and aren't rebuilt, if the sources for compiling it is an entirely different mechanism.

Note that you may in fact see improvements of the CMake configuration time, since e.g. results of try_compile are cached. This may actually result in a perceived improved build time, if you often rewrite the cmake files and therefore trigger an automatic cmake reconfiguration of your project before the actual build starts. However if you do not change the cmake logic, the use of CMake cache variables doesn't improve build times at all (or conditionally applying other logic resulting in a different amount of work for compiler or linker).

Note: Another notable use for cache variables is to provide project configuration options to the user. I'm not elaborating on this, since this doesn't affect build times without additional CMake logic dependent on the value influencing the amount of code to build.

Specifying uncached compile-time constants in CMakeLists file

1 Answers1