什么时候应该重新运行cmake？ [英] When should I rerun cmake?

问题描述

运行 cmake 命令一次以生成构建系统后，如果有的话，应该重新运行 cmake command？

生成的构建系统可以检测相关的 CMakeLists.txt 文件中的更改，并相应地进行操作。您可以在生成的Makefile中看到这样做的逻辑。

我应该何时重新运行 cmake ？答案取决于所使用的发电机吗？

此博客帖子（在标题调用CMake多次下）指出了对此问题的混淆，并指出答案实际上是从不，无论的发电机，但我发现令人惊讶。是真的吗？

解决方案

答案很简单：
cmake 二进制当然需要重新运行每次你改变任何构建设置，但不需要通过设计来做;

由cmake 创建的构建目标会自动包含每个文件的检查[从主CMakeLists.txt文件开始]涉及或包括生成当前的Makefile / VS项目/集合。当调用 make （假设为unix）时，如果需要，自动触发之前执行的 cmake 所以你生成的项目包括调用cmake本身的逻辑！由于所有命令行参数最初通过（例如 cmake -DCMAKE_BUILD_TYPE = RELEASE .. 将存储在 CMakeCache.txt ，你不需要重新指定后续调用中的任何一个，这就是为什么项目也可以运行 cmake ，知道它仍然是你想要的。 p>

一些更详细的信息：
CMake生成包含Makefile / Project生成中涉及的所有文件的保存文件，参见例如我的< binary-dir> /CMakeFiles/Makefile.cmake 文件使用MSYS makefiles：

  ＃顶层Makefile是从以下文件生成的：
 set（CMAKE_MAKEFILE_DEPENDS 
CMakeCache.txt
C：/ Program Files（x86）/CMake/share/cmake-3.1/模块/ 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）
  

$ b b

对任何这些文件的任何修改都会在您选择开始构建目标时触发另一个cmake运行 。我真的不知道如何细致的那些依赖关系跟踪在CMake，即如果一个目标将只是建立，如果任何变化，其他地方不会影响目标的编译。我不会指望它，因为这可以很快弄乱，反复CMake运行（正确使用缓存功能）是非常快的反正。

唯一的情况下，你需要重新运行 cmake 是在您启动项目（MyProject）后更改编译器;但是即使这种情况也是由更新的CMake版本自动处理的（有一些叫喊： - ））。

回复评论的其他评论：

有些情况下，你需要手动重新运行cmake，这是每当你编写你的配置脚本，以至于cmake不能检测到你创建的文件/依赖关系。一个典型的情况是，你的第一个cmake运行创建文件使用例如。 execute_process ，然后使用 file（GLOB ..）来包含它们。这是BAD样式，文件的CMake文件明确说

注意：我们不建议使用GLOB从源代码树中收集源文件列表。如果在添加或删除源时没有CMakeLists.txt文件更改，那么生成的构建系统无法知道何时请求CMake重新生成。

Btw这个注释也阐明了生成的构建系统上面解释的自我调用： - ）

正确的方式来处理这种情况，在配置期间创建源文件是使用 add_custom_command（OUTPUT ...），以便CMake感知正在生成的文件并正确跟踪更改。如果由于某些原因，你不能/不会使用 add_custom_command ，你仍然可以使用源文件属性 GENERATED 。任何具有此标志集的源文件都可以硬编码为目标源文件，并且CMake不会在配置时抱怨丢失的文件（并且希望此文件在第一次.cmake运行期间生成一些时间。）

After running the cmake command once to generate a build system, when, if ever, should I rerun the cmake command?

The generated build systems can detect changes in the associated CMakeLists.txt files and behave accordingly. You can see the logic for doing so in generated Makefiles. The exact rules for when this will happen successfully are mysterious to me.

When should I rerun cmake? Does the answer depend on the generator used?

This blog post (under heading: "Invoking CMake multiple times") points out the confusion over this issue and states that the answer is actually 'never', regardless of generator, but I find that surprising. Is it true?

解决方案

The answer is simple: The cmake binary of course needs to re-run each time you make changes to any build setting, but you wont need to do it by design; hence "never" is correct regarding commands you have to issue.

The build targets created by cmake automatically include checks for each file subsequently [=starting from the main CMakeLists.txt file] involved or included generating the current set of Makefiles/VS projects/whatever. When invoking make (assuming unix here) this automatically triggers a previous execution of cmake if necessary; so your generated projects include logic to invoke cmake itself! As all command-line parameters initially passed (e.g. cmake -DCMAKE_BUILD_TYPE=RELEASE .. will be stored in the CMakeCache.txt, you dont need to re-specify any of those on subsequent invocations, which is why the projects also can just run cmake and know it still does what you intended.

Some more detail: CMake generates book-keeping files containing all files that were involved in Makefile/Project generation, see e.g. these sample contents of my <binary-dir>/CMakeFiles/Makefile.cmake file using MSYS makefiles:

# 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 trigger another cmake run whenever you choose to start a build of a target. I honestly dont know how fine-grained those dependencies tracking goes in CMake, i.e. if a target will just be build if any changes somewhere else wont affect the target's compilation. I wouldn't expect it as this can get messy quite quickly, and repeated CMake runs (correctly using the Cache capabilities) are very fast anyways.

The only case where you need to re-run cmake is when you change the compiler after you started a project(MyProject); but even this case is handled by newer CMake versions automatically now (with some yelling :-)).

additional comment responding to comments:

There are cases where you will need to manually re-run cmake, and that is whenever you write your configure scripts so badly that cmake cannot possibly detect files/dependencies you're creating. A typical scenario would be that your first cmake run creates files using e.g. execute_process and you would then include them using file(GLOB ..). This is BAD style and the CMake Docs for file explicitly say

Note: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.

Btw this comment also sheds light on the above explained self-invocation by the generated build system :-)

The "proper" way to treat this kind of situations where you create source files during configure time is to use add_custom_command(OUTPUT ...), so that CMake is "aware" of a file being generated and tracks changes correctly. If for some reason you can't/won't use add_custom_command, you can still let CMake know of your file generation using the source file property GENERATED. Any source file with this flag set can be hard-coded into target source files and CMake wont complain about missing files at configure time (and expects this file to be generated some time during the (first!) cmake run.

这篇关于什么时候应该重新运行cmake？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！