CMake + Ninja构建不跨库并行化

Question

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

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

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

在设置CMake文件以表示库之间的依赖关系的最佳方法方面，我缺少了什么吗？或者这是忍者如何工作的一个不可逾越的限制？

Answer 1

这是最近在CMake邮件列表中被问到的。其中一个开发人员的响应确认您报告的行为是故意的：

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

虽然在某些情况下可以对CMake进行改进以放松该约束，但这似乎还没有完成(截至CMake 3.6)。在Kitware问题跟踪器中已经有了一个开票。

更新：-这似乎是固定在CMake 3.9.0中，尽管这种变化导致了一个回归，然后是固定在3.12.0，或可能3.11.2。