依赖性检查 - 如何清理带有错误 makefile 的项目
我有一个非常大的 C 项目,其中有许多单独的 C 文件和标头以及许多贡献者。 许多贡献者对 makefile 和依赖项没有深入的了解,从而导致了一个并不罕见的问题:您几乎总是必须“make clean”,然后才能相信“make”已产生正确的输出。
如果 make 需要几分钟,这不会是一个问题,但现在在一台快速机器上需要将近 2 个小时,人们开始签入在 make 时有效的代码,但他们不先清理,他们的代码最终会崩溃构建。 不要问为什么在削减新基线之前构建经理没有捕获这些......
是的,我们不应该让它走这么远。
是的,我们正在教育我们的开发人员。
和往常一样,我们没有时间停止一切并手动修复。
我认为有这样的工具:
- 是否有自动化工具可以帮助从 C 和 H 文件为现有项目构建正确的依赖关系信息?
- 是否有自动化工具可以根据 makefile 描述依赖关系信息?
- 是否有一个圣杯工具来描述上述两个依赖树之间的差异?
但是还可以/应该做什么来解决这个问题呢?
预先感谢...-
亚当
I have a very large C project with many separate C files and headers and many dozens of contributors. Many contributors do not have a strong knowledge of makefiles and dependencies, resulting in the not uncommon problem where you almost always have to "make clean" before you can trust "make" to have produced correct output.
If make took minutes, this wouldn't be an issue, but it's nearly 2 hours on a fast machine now, and people are starting to check in code that works when they make, but they don't clean first and their code ultimately breaks the build. Don't ask why these aren't caught by the build manager before a new baseline is cut...
Yes, we shouldn't have let it go this far.
Yes, we're educating our developers.
As usual, we don't have time to stop everything and fix it by hand.
I'm thinking there are tools along these lines:
- Are there automated tools to help build correct dependency information for an existing project from the C and H files?
- Are there automated tools to describe dependency information according to the makefiles?
- Is there a holy grail of a tool to describe the differences between the above two dependency trees?
But what else can/should be done to resolve this issue?
Thanks in advance...
-Adam
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
从 Make 切换到自动检测依赖关系的工具可能是最简单的方法。 例如, SCons 不会让您列出依赖项,而是自动解析正在编译的文件并查找包含。 您只需指定应编译哪些文件以及哪些文件进入哪些可执行文件即可。 由于您的开发人员并不是真正的 Make 专家,因此切换构建系统会更容易。
如果您坚持使用 Make,另一种选择是使用 gcc -M 选项自动检测依赖项。 自动发现 C 依赖项问题的答案有一个示例,说明如何让 makefile 自动发现依赖项,以便您无需手动指定它们。
It might be easiest to switch from Make to a tool which automatically detects dependencies. For example, SCons doesn't make you list dependencies but instead automatically parses the files being compiled and looks for includes. You simply specify which files should be compiled and which files go into which executables. Switching build systems will be easier for the fact that your developers aren't really Make experts.
Another alternative if you stick with Make is to use the
gcc -M
option to automatically detect dependencies. The answer to the Automatically discovering C dependencies question has an example of how to have your makefiles automatically discover dependencies so that you don't need to specify them by hand.汽车制造商 autoconf 组合:
http://sources.redhat.com/automake/automake.html#Introduction
更多:
http://sources.redhat.com/automake/ automake.html#Why-Autotools
HTH
automake & autoconf combo:
http://sources.redhat.com/automake/automake.html#Introduction
more:
http://sources.redhat.com/automake/automake.html#Why-Autotools
HTH
解决这个问题的规范方法是让编译器自动为您生成依赖信息。 像这样的东西(假设是 gcc,你需要检查你的编译器是否有类似的选项)
GNU Make 手册有一章关于 自动生成先决条件。
编辑:我通常建议人们在遇到此类问题时开始使用 CMake 。
The canonical way of solving this is to let the compiler automatically generate dependency info for you. Something like this (assuming gcc, you'll want to check your compiler for similar options)
The GNU Make manual has a chapter on automatically generating prerequisites.
EDIT: I usually recommend people to start using CMake when they have this kind of issue.
我们在我的工作场所也遇到同样的问题。 合并或签入后,主干总是被破坏。
我们设置了一个连续集成构建机器,与大约 45 分钟相比,它在大约 45 分钟内完成了 make clean在开发机器上需要 2 小时。集成服务器每 2 小时轮询一次 SVN 存储库以获取新的签入并启动 make clean。
这样,我们就可以准确监控构建何时被破坏并立即修复。
我们使用 Hudson 作为我们的持续集成服务器,它免费且开源,它是一件艺术品,而且非常简单建立。 另外,用户界面非常直观,所有其他开发人员都喜欢它。
干杯,
We have the same problem at my workplace. The Trunk was always broken after merges or check-ins.
We set up a continuous integation build machine that does a make clean in about 45 minutes compared to about 2 hours on a dev machine.The integration server polls the SVN repository every 2 hours for new check-ins and starts a make clean.
That way, we can monitor exactly when the build was broken and fix it right away.
We use Hudson as our continuous integration server, its free and open source, its a work of art and very easy to set up. Plus the User Interface is very intuitive, all the other developers love it.
Cheers,