我们有一个 (C++) 程序，它被设置为一系列具有嵌套层次结构的共享库。也就是说，libB.so 使用来自 libA.so 的函数并因此链接到 libA.so，libC.so 使用来自 libB.so 和 libA.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 工作方式无法克服的限制？
最佳答案
这是最近在 CMake 邮件列表上提出的问题。 response其中一位开发人员确认您报告的行为是故意的:
This is unfortunately necessary to get correct builds for CMake projects in general because we support cases where add_custom_command is used in library "foo" to generate a header file that is included during compilation in library "bar" that links to "foo", but we have no good way to express this dependency besides the ordering dependency of bar on foo.
虽然在某些情况下可能会改进 CMake 以放宽该约束，但这似乎尚未完成(截至 CMake 3.6)。有一个 open ticket Kitware 问题跟踪器中已经对此进行了说明。
更新:这似乎是 fixed in CMake 3.9.0 , 尽管这种变化导致了随后的回归 fixed in 3.12.0 , 或 possibly 3.11.2 .
关于c++ - CMake + Ninja 构建不会跨库并行化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36164058/