等待 CMake 构建中的目标答案

【问题标题】：Waiting for targets in a CMake build等待 CMake 构建中的目标
【发布时间】：2020-12-28 14:34:54
【问题描述】：

我认为我确实有 CMake 顺序/并行问题。

在我的构建过程中，我需要构建一个工具，然后由其他目标使用。该工具是一个单独的项目，带有一个 CMakeLists.txt 文件，如下所示：

project (package-tool LANGUAGES CXX)
set (SOURCES package_tool.cpp)
...

在构建的后期，这个顶级目标被其他目标引用：

...
add_custom_command (OUTPUT "${DST_FILE}"
                            COMMAND ${PACKAGE_COMMAND} "${DST_FILE}"
                            COMMAND package-tool.exe -e "${DST_FILE}"
                            DEPENDS ${PACKAGE_DEPENDENCIES} package-tool)
...

我使用 ninja 进行构建，并且依赖项（ninja -t 依赖）看起来正确。此外，构建命令（ninja -t 命令）也很有意义。但是：有时，构建会失败。该消息没有意义，内容如下：

这个版本的package-tool.exe与版本不兼容您正在运行的 Windows。

由于构建并行运行（32 个进程），我怀疑在第二个目标中使用生成的 exe 时 package-tool 目标没有完成，这可能会导致这个令人困惑的错误消息。同样，大多数时候构建成功，但每运行 10 次或 20 次，它就会失败并显示该消息。

所以现在我的问题是：

有没有办法在 CMake/Ninja 的并行构建中等待工具/目标构建完成？
或者如何正确处理在同一构建过程中构建构建工具的任务？

提前谢谢你！

【问题讨论】：

“我怀疑在第二个目标中使用生成的 exe 时， package-tool 目标没有完成” - 正如你所说，ninja 会按预期输出依赖项。那么，您是否怀疑 ninja 不遵循这些依赖关系？那么问题不应该是关于 CMake 和写作CMakeLists.txt，而是关于 ninja 及其错误行为。您收到错误的原因可能是其他地方。但我们只能猜测，而猜测并不是 Stack Overflow 的工作原理。
嗯...我认为你是对的。 CMake 处理并发是没有意义的，忍者应该这样做。重新考虑一下，我会假设 ninja 步骤只是等到它所依赖的文件全部存在，因此 CMake/Ninja 域之外的另一个导致该问题的原因可能确实存在。感谢您的洞察力！

标签： cmake build ninja

【解决方案1】：

实际上是依赖于可执行文件并运行可执行文件，而不是目标。不要担心任何.exe 后缀。另外最好不要假设 add_custom_command 将在 CMAKE_RUNTIME_OUTPUT_DIRECTORY 中运行 - 如果您依赖于特定目录，请使用 WORKING_DIRECTORY 显式设置它。

add_custom_command (
    OUTPUT "${DST_FILE}"
    COMMAND ${PACKAGE_COMMAND} "${DST_FILE}"
    COMMAND $<TARGET_FILE:package-tool> -e "${DST_FILE}"
    DEPENDS ${PACKAGE_DEPENDENCIES} $<TARGET_FILE:package-tool>
)

【讨论】：

而不是$<TARGET_FILE:package-tool> CMake 允许只指定一个目标名称：COMMAND package-tool -e "${DST_FILE}"。此外，通过这两种方式 - TARGET_FILE 或简单的目标名称 - CMake 会自动从 package-tool 添加 target 级别的依赖项。是否需要来自 package-tool 的 file 级依赖关系取决于项目。这种 file 级别的依赖只会在可执行文件发生更改时强制重新运行自定义命令（更准确地说，是依赖于命令的自定义目标）。