Question

我有一个非常大的C项目，包含许多单独的C文件和标题以及许多贡献者。许多贡献者对makefile和依赖关系没有很强的了解，因此在你可以信任“make”以产生正确的输出之前，几乎总是必须“干净”的问题并不罕见。

如果make需要几分钟，这不会是一个问题，但现在快速机器上已经有近2个小时了，而且人们开始检查代码在他们制作时有效，但他们不会先清理它们代码最终打破了构建。不要问为什么在新基线被切断之前，构建管理器没有抓住这些内容......

是的，我们不应该让它走得这么远。

是的，我们正在教育我们的开发人员。

像往常一样，我们没有时间停下来并手工修理。

我认为这些方面有工具：

但是还有什么可以/应该做的来解决这个问题？

提前致谢...

- 亚当

Answer 1

从Make切换到自动检测依赖关系的工具可能最容易。例如，SCons不会使您列出依赖项，而是自动解析正在编译的文件并查找包含。您只需指定应编译哪些文件以及将哪些文件放入哪些可执行文件中。对于您的开发人员并非真正成为专家而言，切换构建系统会更容易。

如果坚持使用Make，另一种选择是使用gcc -M选项自动检测依赖关系。 Automatically discovering C dependencies问题的答案有一个示例，说明如何让makefile自动发现依赖关系，这样您就不需要手动指定它们了。

Answer 2

automake＆amp; autoconf combo：

更多：

HTH

Answer 3

我们在工作场所遇到同样的问题。合并或签到后，Trunk总是被打破。

我们设置了一个continuous integation构建机器，在大约45分钟内完成make clean，而在dev机器上大约需要2个小时。集成服务器每2小时轮询SVN存储库以进行新的签入和启动一个干净的。

这样，我们可以准确监控构建何时被破坏并立即修复。我们使用Hudson作为我们的持续集成服务器，它的免费和开源，它是一件艺术品，非常容易设置。此外，用户界面非常直观，所有其他开发人员都喜欢它。

干杯，

Answer 4

解决此问题的规范方法是让编译器自动为您生成依赖项信息。这样的事情（假设gcc，你会想要检查编译器的类似选项）

SOURCES=foo.c bar.c

%.d: %.c
    $(CC) $(CFLAGS) -MM $< >$@ 

include $(SOURCES:.c=.d)

编辑：我通常建议人们在遇到此类问题时开始使用CMake。