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

CMake + Ninja build does not parallelize across libraries

本文关键字：并行化 构建 CMake+Ninja      更新时间：2023-10-16

我们有一个（C++）程序，它被设置为一系列具有嵌套层次结构的共享库。也就是说，libB.so使用来自的函数，从而链接到libA.so，libC.so使用来自和链接到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文件以表达库之间依赖关系的最佳方式，我是否缺少一些东西？还是这是忍者工作方式的一个不可逾越的限制？

这是最近在CMake邮件列表上问到的。其中一个开发者的回应证实了你报告的行为是故意的：

不幸的是，这对于获得CMake项目的正确构建是必要的一般来说，因为我们支持使用addcustom_command的情况在图书馆"；foo"；生成包含在图书馆编译"；条"；链接到"；foo"；，但是我们没有好的除了bar的排序依赖关系之外，这种依赖关系的表达方式在foo上。

虽然在某些情况下，CMake可能会得到改进，以放松这一限制，但这似乎还没有完成（截至CMake 3.6）。在Kitware问题跟踪器中已经有了这方面的开放门票。

更新：这似乎在CMake 3.9.0中得到了修复，尽管这一变化导致了随后在3.12.0或3.11.2中修复的回归。

相关文章：