4

我们有一个（C++）程序，它被设置为一系列具有嵌套层次结构的共享库。也就是说，libB.so 使用函数 from 并因此链接 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 文件以表达库之间的依赖关系的最佳方式，我是否遗漏了什么？或者这是忍者工作方式的一个不可逾越的限制？

4

1 回答 1

7

这是最近在 CMake 邮件列表上提出的。一位开发人员的回复证实您报告的行为是故意的：

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

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

更新：这似乎已在 CMake 3.9.0 中修复，尽管该更改导致回归，随后在 3.12.0或可能 3.11.2中修复。

于 2016-07-17T21:01:34.740 回答