确定使用 makefile 和 ant 脚本的构建过程中的所有文件依赖项
我试图了解代码库的构建过程。该项目同时使用 autoconf(生成 makefile 的配置脚本)和 Maven。
我希望能够识别项目中的所有文件依赖项,以便对于最终由构建生成的任何输出文件,我可以识别它的实际生成方式。最终,我想使用 graphviz 之类的东西生成一个图表来可视化依赖关系,但现在我只是想提取它们。
有没有自动化的方法来做到这一点?换句话说,给定一些 makefile 和 Maven 或 ant XML 文件以及顶级目标的名称,是否有一种方法可以识别将生成的所有文件、用于生成它们的程序以及输入文件与那些程序相关?
I'm trying to understand the build process of a codebase. The project uses both autoconf (configure scripts that generate makefiles) and Maven.
I would like to be able identify all of the file dependencies in the project, so that for any output file that ends up being generated by a build, I can identify how it was actually produced. Ultimately, I'd like to generate a diagram using something like graphviz to visualize the dependencies, but for now I just want to extract them.
Is there any automated way to do this? In other words, given some makefiles and Maven or ant XML files, and the name of the top-level target, is there a way to identify all of the files that will be generated, the programs used to generate them, and the input files associated with those programs?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Electric Accelerator 和 ClearCase 是两个通过运行构建并观察其执行情况(可能是通过拦截操作系统调用)来执行此操作的系统。这样做的优点是适用于任何工具,并且不受有缺陷的 makefile 的影响(提示:它们都是有缺陷的)。
对于重要的 makefile 来说,这可能是唯一可靠的方法,因为它们都会执行诸如动态生成新 make 规则之类的操作,或者具有依赖于磁盘上未在规则中明确列出的文件的存在的行为。
Electric Accelerator and ClearCase are two systems that do this, by running the build and watching what it does (presumably by intercepting operating system calls). This has the advantage of working for any tool, and being unaffected by buggy makefiles (hint: they're all buggy).
That's probably the only reliable way for non-trivial makefiles, since they all do things like generating new make rules on the fly, or have behaviour that depends on the existence of files on disk that are not explicitly listed in rules.
我不知道 Maven 方面,但是一旦您
./configure
d 项目,您可以通过make -pd
的输出进行 grep (make --print-data-base --dry-run
) 来查找依赖项。如果它基于递归 make,这可能会更烦人,但仍然可以管理。请注意,如果您使用 automake,它会计算详细的依赖项作为编译的副作用,因此在进行完整构建之前,您不会获得
#include
d 标头上的所有依赖项。I don't know about the maven side, but once you've
./configure
d the project, you could grep through the output ofmake -pd
(make --print-data-base --dry-run
) to find the dependencies. This will probably be more annoying if it's based on recursive make, but still manageable.Note that if you're using automake, it computes detailed dependencies as a side-effect of compilation, so you won't get all the dependencies on
#include
d headers until you do a full build.