调试CMake / Make并行构建的依赖项

Question

我管理工作是一个复杂的C ++项目，其构建定义是用CMake编写的，构建本身是通过调用make获得的。源树由许多模块组成，并且可高度并行化。

线性构建总是成功，而并行构建大多数时间都是成功的。当在这样的构建期间遇到依赖性问题时，我通常会去修复它，但我想以编程方式测试依赖项，而不是在问题发生时修复它们。

理想的解决方案是遍历CMake中的所有依赖项并修复它们，但这在实践中并不总是可行的，因为我们大量使用自定义宏来处理某些特定于我们的依赖项。源树（我不能详细说明，抱歉）。因此，我正在考虑以不同方式（并且可能有效地）解决问题，尝试尽可能多地重用标准工具。

1. 我的第一个想法是在Make作业调度中注入某种“随机性”，因此构建机器可以无限期地尝试通过重建树来执行不同的编译路径，直到遇到故障。但是，另一个问题(here)指出Make无法使用此功能。

2. 所以我尝试了另一个解决方案：我创建了一个围绕g++的包装器脚本，它睡眠时间为$RANDOM秒，以便在Make作业调度程序中带来一些噪音。当然，这种解决方案的缺点是增加了编译时间 然而，这个部分解决方案有一个根本的缺陷：如果发现问题，则证明缺少依赖关系，但是，如果没有生成错误，我们就无法证明所有依赖关系都是正确的。

你怎么看？我怎么能实现我的目标？我更喜欢重用标准工具的解决方案，并且可以应用于广泛的受众。

感谢。

Answer 1

如果你真的想有效地解决这个问题，我认为你需要使用更好的make。 Electric Make（ElectricAccelerator的一部分）是make的GNU make兼容变体，它在构建期间监视文件系统访问，并自动detect and correct problems caused by out-of-order execution。此外，ElectricMake可以生成annotated build log，它将显示构建中每个作业访问的文件，以及作业之间的依赖关系（显式和隐式），您可以使用它们来纠正缺少的依赖关系。你的文件。

您可以下载并试用免费升级版的ElectricAccelerator ElectricAccelerator Huddle。

免责声明：我是ElectricAccelerator的架构师和技术负责人。

Answer 2

您可以尝试自己分析依赖项。 Cmake可以很容易地在dot / graphviz中生成依赖图： http://www.cmake.org/Wiki/CMake:For_CMake_Hackers

某些图论可能有助于您的分析： http://en.wikipedia.org/wiki/Graph_theory