c - 依赖性检查 - 如何清理带有错误 makefile 的项目

Question

我有一个非常大的 C 项目，其中包含许多单独的 C 文件和头文件以及许多贡献者。许多贡献者对 makefile 和依赖项没有深入的了解，这导致了一个常见的问题，即您几乎总是必须“make clean”才能相信“make”产生正确的输出。

如果 make 需要几分钟，这不会是一个问题，但现在在一台快速的机器上将近 2 个小时，人们开始检查他们制作时可以工作的代码，但他们没有先清理，他们的代码最终会中断构建。不要问为什么在新基线被削减之前构建经理没有捕捉到这些......

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

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

像往常一样，我们没有时间停止一切并手动修复它。

我认为有这些方面的工具：

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

提前致谢...

-亚当

score 6 · Accepted Answer

从 Make 切换到自动检测依赖项的工具可能是最简单的。例如，SCons不会让您列出依赖项，而是自动解析正在编译的文件并查找包含。您只需指定应该编译哪些文件以及哪些文件进入哪些可执行文件。由于您的开发人员并不是真正的 Make 专家，因此切换构建系统会更容易。

如果您坚持使用 Make，另一种选择是使用gcc -M自动检测依赖项的选项。自动发现 C 依赖项问题的答案有一个示例，说明如何让您的 makefile 自动发现依赖项，以便您无需手动指定它们。

score 4 · Accepted Answer

自动制作和自动配置组合：

更多的：

高温高压

score 3 · Accepted Answer

我们在我的工作场所也有同样的问题。合并或签入后，Trunk 总是坏掉。

我们设置了一个持续集成构建机器，它在大约 45 分钟内完成清理，而在开发机器上大约需要 2 小时。集成服务器每 2 小时轮询 SVN 存储库以获取新签入并启动清理。

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

干杯，

score 2 · Accepted Answer

解决这个问题的规范方法是让编译器自动为你生成依赖信息。像这样的东西（假设 gcc，你会想检查你的编译器是否有类似的选项）

SOURCES=foo.c bar.c

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

include $(SOURCES:.c=.d)

GNU Make 手册有一章是关于自动生成先决条件的。

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

4 回答 4