CMake + Ninja 构建不会跨库并行化

Question

我们有一个 (C++) 程序，它被设置为一系列具有嵌套层次结构的共享库。也就是说，libB.so 使用函数 from 并因此链接 libA.so，libC.so 使用函数 from 并链接 libB.so 和 libA.so 等。

对于我们当前的 CMake+Ninja 构建系统，我注意到并行构建似乎不会跨库发生。也就是说，虽然 Ninja 通常会使用 12 个内核来构建，但如果我接触了 libA 中的单个源文件但 libC 中的多个源文件，ninja 将只使用单个处理器来构建 libA 源文件，直到 libA.so 被链接，此时它将使用 12 个处理器来编译 libC 源文件。 - 如果 libA 源代码编译出错，它甚至不会尝试将 libC 文件编译为目标文件，即使我将 -k 传递给 ninja。

当然，libC.so 的链接需要延迟到 libA.so 被链接，但是将源文件编译为 libC 源的目标文件不应该因为 libA 的链接而延迟。

关于设置 CMake 文件以表达库之间的依赖关系的最佳方式，我是否遗漏了什么？或者这是 Ninja 工作方式的一个不可逾越的限制？

Answer 1

这是最近在 CMake 邮件列表中提出的问题。其中一位开发人员的response 确认您报告的行为是故意的：

不幸的是，这对于获得 CMake 项目的正确构建是必要的 一般来说，因为我们支持使用 add_custom_command 的情况 在库“foo”中生成一个头文件，该文件包含在 在链接到“foo”的库“bar”中编译，但我们没有好的 除了 bar 的排序依赖关系之外，表达这种依赖关系的方法 在 foo 上。

虽然在某些情况下可能会改进 CMake 以放松该约束，但这似乎还没有完成（从 CMake 3.6 开始）。在 Kitware 问题跟踪器中已经有一个open ticket。

更新：这似乎是 fixed in CMake 3.9.0，尽管这种变化导致了回归，随后是 fixed in 3.12.0 或 possibly 3.11.2。