The answer is simple: In the cmake binary format, of course, you need to restart it every time you make changes to any build parameter, but you do not need to do this by design; therefore, "never" is correct with respect to the commands that you must execute.
The build goals created by cmake automatically include checks for each file subsequently [= starting from the main CMakeLists.txt file] involved or including the creation of the current set of Makefiles / VS / whatever projects. When make invoked (assuming unix is used here), the previous cmake execution is automatically started if necessary; therefore, your generated projects include logic to invoke CMake itself! Since all command line parameters are initially passed (for example, cmake -DCMAKE_BUILD_TYPE=RELEASE .. will be saved in CMakeCache.txt , you do not need to re-specify any of them on subsequent calls, so projects can also run cmake and still know it does what you intended.
Additional information: CMake generates accounting files containing all the files involved in the creation of the Makefile / Project, see, For example, these sample contents of my <binary-dir>/CMakeFiles/Makefile.cmake file using MSYS make files:
# The top level Makefile was generated from the following files: set(CMAKE_MAKEFILE_DEPENDS "CMakeCache.txt" "C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/CMakeCCompiler.cmake.in" "C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/RepositoryInfo.txt.in" "<my external project bin dir>/release/ep_tmp/IRON-cfgcmd.txt.in" "../CMakeFindModuleWrappers/FindBLAS.cmake" "../CMakeFindModuleWrappers/FindLAPACK.cmake" "../CMakeLists.txt" "../CMakeScripts/CreateLocalConfig.cmake" "../Config/Variables.cmake" "../Dependencies.cmake" "CMakeFiles/3.1.0/CMakeCCompiler.cmake" "CMakeFiles/3.1.0/CMakeRCCompiler.cmake")
Any modification to any of these files will cause another cmake to run whenever you decide to start building the target. I honestly don't know how fine-grained dependency tracking goes in CMake, i.e. If the goal is simply built, if any changes in another place do not affect the target compilation. I would not expect this, as it can become quite messy, and retrying CMake (using Cache features correctly) is very fast anyway.
The only time you need to restart cmake is when you change the compiler after running project(MyProject) ; but even this case is handled automatically by new versions of CMake (with some shouts :-)).
additional commentary on comments:
There are times when you need to manually restart cmake, and this happens when you write configure scripts so poorly that cmake cannot detect the files / dependencies that you create. A typical scenario would be that your first cmake run creates files using, for example, execute_process , and you would include them using file(GLOB ..) . This is a bad style and CMake Docs for the file explicitly say
Note. We do not recommend using GLOB to collect a list of source files from the source tree. If the CMakeLists.txt file does not change when adding or removing the source, the generated build system cannot know when to request regeneration of CMake.
By the way, this comment also sheds light on the explanation of self-triggering by the generated assembly system described above :-)
The “correct” way to treat such situations when you create the source files during setup is to use add_custom_command(OUTPUT ...) so that CMake knows the file being created and correctly tracks changes. If for some reason you cannot / will not use add_custom_command , you can still tell CMake to generate your file using the property of the original GENERATED file. Any source file with this set of flags can be hardcoded to the target source files, and CMake will not complain about missing files during setup (and expects this file to be created for some time during the (first!) Cmake run.