为并行版本调试CMake/Make dependencies

Question

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

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

理想的解决方案是遍历CMake中的所有依赖关系并修正它们，但实际上这并不总是可行，因为我们大量使用自定义宏来处理特定于源代码树的某种依赖关系（我不能详谈，对不起）。所以，我正在考虑以不同的方式解决问题（并且可能有效），尽可能地重用标准工具。

1. 我首先想到的是注入了某种“随机性”在Make作业调度，所以成型机可以尝试无限期，直到遇到一个重建故障树行使不同的编译路径。然而，另一个问题(here)指出，该功能在Make中不可用。

2. 所以我试图用另一种解决办法：我创建了一个包装脚本左右g++该睡了$RANDOM秒数，带来一些噪音在Make工作调度。这个解决方案的缺点当然是增加了编译时间。然而，这种部分解决方案存在一个基本缺陷：如果发现问题，则证明缺少依赖关系，但是，如果没有生成错误，我们不能证明所有依赖关系都是正确的。

你觉得呢？我怎么能达到我的目标？我更喜欢重复使用标准工具的解决方案，并且可以应用于广泛的受众。

谢谢。

Answer 1

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

您可以下载并试用ElectricAccelerator的免费增值版本ElectricAccelerator Huddle。

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

Answer 2

您可以尝试分析依赖关系本身。CMake的可点产生依赖关系图/ graphviz的相当容易： http://www.cmake.org/Wiki/CMake:For_CMake_Hackers

一些图论可能在您的分析帮助： http://en.wikipedia.org/wiki/Graph_theory