我管理一个复杂的 C++ 项目，它的构建定义被写入，CMake构建本身是通过调用make. 源代码树由许多模块组成，具有高度的可并行性。
线性构建总是成功的，而并行构建大多数时候都是成功的。当在这样的构建过程中遇到依赖问题时，我通常会去修复它，但我想以编程方式测试依赖关系，而不是在问题发生时修复它们。
理想的解决方案是遍历所有依赖CMake项并修复它们，但这在实践中并不总是可行的，因为我们大量使用自定义宏来处理特定于我们的源树的某种依赖项（我无法详细说明， 对不起）。因此，我正在考虑以不同的方式（并且可能有效地）解决问题，尝试尽可能多地重用标准工具。
Make我的第一个想法是在作业调度中注入某种“随机性” ，因此构建机器可以通过重建树来无限期地尝试不同的编译路径，直到遇到故障。然而，另一个问题（此处）指出，此功能在Make.所以我尝试了另一种解决方案：我创建了一个包装脚本，
g++它会休眠几秒钟，以在作业调度程序$RANDOM中带来一些噪音。Make当然，这种解决方案的缺点是增加了编译时间。
然而，这种部分解决方案有一个根本性的缺陷：如果发现问题，则证明缺少依赖项，但如果没有产生错误，则无法证明所有依赖项都是正确的。
你怎么看？我怎样才能实现我的目标？我更喜欢重用标准工具并且可以应用于广泛受众的解决方案。
谢谢。