When to reconfigure vs configure from scratch? Why?

In my testing, I’ve noticed that there are many configuration changes that do not affect the build. Say I initially configure and build my project like this (I’m testing with 3.17):

cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake -S . -B .build
cmake --build .build

Then say I make changes to the toolchain file and try to reconfigure:

cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake -S . -B .build

Exact same command as before, but I get this error:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_TOOLCHAIN_FILE

The documentation for CMAKE_TOOLCHAIN_FILE does not say it is ignored after the first configuration. Why is it?

Now let’s say I reconfigure, changing a variable on the command line:

cmake -DBUILD_SHARED_LIBS=ON -S . -B .build

If I branch on that variable to change some options to a call to find_library or find_path, the call will return the same results as it did in the first configuration. I guess if the cache is present, then those functions just return whatever is in there.

If I have a specific configuration change in mind, how can I tell ahead of time whether reconfiguration will incorporate that change? When is reconfiguration prohibited? When is it recommended? Should I just always start a fresh configuration (throwing away intermediate build artifacts) after every configuration change?

In general, you can’t. Most projects are OK with flipping options and running off of cached results, but others are not. I’ll also note that Find modules usually want everything they make cleared before finding a different installation of the same package though.

It probably should. CMake doesn’t support changing the compiler after the initial configure (where a compiler is successfully found) because it builds all kinds of knowledge up based on that discovered compiler that undoing it all is very unreliable, so it’s just best to start from scratch in that case.

1 Like