It’s common that I want CMake to reconfigure but with the same command I used to configure a given existing build directory, and I don’t remember the exact command. Is there a way to get this effect?
I would use cmake presets to simplify this. 
bash-5.2$ cmake --preset Release --fresh
Preset CMake variables:
CMAKE_BUILD_TYPE="Release"
CMAKE_CXX_EXTENSIONS:BOOL="FALSE"
CMAKE_CXX_FLAGS="-Wall -Wextra -Wpedantic -Wshadow -Wconversion -Wsign-conversion -Wcast-align -Wcast-qual -Wnull-dereference -Woverloaded-virtual -Wformat=2 -Werror"
CMAKE_CXX_STANDARD="20"
CMAKE_CXX_STANDARD_REQUIRED:BOOL="TRUE"
CMAKE_EXPORT_COMPILE_COMMANDS:BOOL="TRUE"
CMAKE_MESSAGE_LOG_LEVEL="WARNING"
MYLIB_BUILD_EXAMPLES:BOOL="TRUE"
MYLIB_BUILD_TESTS:BOOL="TRUE"
MYLIB_SHARED_LIBS:BOOL="TRUE"
-- Configuring done (3.7s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/clausklein/Workspace/cpp/cpp-lib-template/build
bash-5.2$
If you don’t know the build generator you can generally do
cmake --build build -t rebuild_cache
CMake does not save the command line used. Even if it did, it wouldn’t be reliable. CMake caches information between runs. The effect of the latest run should be thought of as the accumulation of earlier runs with the latest command line.
Some command-line options are not cached because they don’t affect the build, they only affect the current CMake execution in ways that don’t change the generated build project files. The various -W options like -Wno-dev or -Wdeprecated are one example, as are options like --graphviz or --log-level. You can’t know whether the last cmake invocation had such options.
As others have already mentioned, the rebuild_cache build target is one way to at least re-run CMake with the currently cached details. That’s probably the closest to what you’ve asked for. I’m not sure if it is supported by all CMake generators, it isn’t mentioned anywhere in the official documentation (which actually surprises me).
1 Like
I don’t want to use the current cache details; I want the effect of blowing away the build directory and starting over with the original command line.
I can always make a wrapper script to do this. There are unfortunately many front-end conveniences I want from CMake that could only be accomplished with a wrapper script
… as I have written.
I frankly find CMake presets unhelpful. They are commonly checked into projects (want to make the project work OOTB with VSCode’s CMake extension? You need a preset), but then, in my experience, they are never what any individual needs except the person that wrote them. The fact that the file is checked in then discourages individual customization, which is bad for this particular use case. Finally, once I’ve found a command-line I want to use, I then need to translate it into JSON, which is inconvenient. What I’m asking for here is a convenience feature. I’ve yet to see the light with presets, obviously.
And often you have some environment shell script that works around the general problem of relocatable SDKs.
Presets even in combination with a toolchain file often cannot replace that script.
So you have an example?
I look at Yocto SDKs even in form of Boot2Qt installations.
You cannot solve a variable install location solely with fixed text like in a preset. The work-arounds usually use some environment variable. But that’s just the same as an environment script under the hood, maybe with the advantage to not rely on a specific interpreter.
The modern way are build containers that solve it by selecting a location and setting up the environment.
Or some central thing you can ask like some IDEs do.
Whatever you do, the problem of mapping a preset name to a variable environment stays.