2

I have vague understanding of what CMake cache is, but I am not sure why it is used for options.

When it comes to options it seems like horrible idea. This is a quote from answer about why if does not work with options:

So to test the logic in your CMakeLists, delete the cache each time before re-running CMake.

I am not a functional programming person, but for me it is totally insane to have sticky state for options like this.

I presume there is some reason why CMake choose to have this design. In other words what is the motivation for putting options in cache?

NoSenseEtAl
  • 28,205
  • 28
  • 128
  • 277
  • 1
    It's weird that when CMakeLists.txt changes, cache doesn't reflect the change... I'd like to have a list for "you need to clear the cache to take effect." – Louis Go Sep 16 '21 at 09:43
  • Because usual cmake workflow is to initialize something like `cmake -S . -B debug -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=~/.cache` once and `cmake --build debug` with possibly `--target install` one or more times. Do you want to configure cmake and recompile whole project with this long command more than once? Also you can modify a single option `cmake -S . -B debug -DCMAKE_BUILD_TYPE=AddressSanitize` and recompile/run with address sanitizer in place, why would you want to specify all options all in a single command, every single time when `cmake --build debug` is enough? – Kaihaku Sep 16 '21 at 12:56
  • Note: For modifying the settings of an existing project cmake-gui works reasonably well. As for why it has been chosen to implement this kind of functionality: CMake is a meta build system, i.e. it creates the build system, but doesn't build the project itself; Now if you consider that changing the `CMakeLists.txt` should automatically update the project using the existing settings, you'll need to persist those settings somewhere on the file system and this place happens to be the cmake cache. – fabian Sep 16 '21 at 18:39

0 Answers0