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

【问题标题】：Dependency checking - how to clean up a project with bad makefiles依赖性检查 - 如何清理带有错误 makefile 的项目
【发布时间】：2010-09-19 09:31:59
【问题描述】：

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

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

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

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

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

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

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

提前谢谢...

-亚当

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

automake 和 autoconf 组合：

HTH

【讨论】：

【解决方案3】：

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

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

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

干杯，

【讨论】：

【解决方案4】：

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

SOURCES=foo.c bar.c

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

include $(SOURCES:.c=.d)

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

【讨论】：