从源代码和可执行文件生成 Makefile?

发布于 2024-11-26 19:41:01 字数 252 浏览 2 评论 0原文

我有一个大型代码库,可以使用旧的自定义构建系统很好地构建,该系统使用一堆 bash 脚本和递归组合的简单 Makefile 拼凑在一起。

我如何使用现代版本的 GNU make 重新创建构建系统? (或其他一些工具。)

代码库很大,分为许多子目录,并且具有重要的跨子文件夹依赖性和系统库链接要求。

由于我可以使用当前的构建系统构建一组启用调试的可执行文件,那么有没有什么方法可以内省这些文件,构建一组新的构建和链接规则?

谢谢

I've got a large code base that builds fine using a old custom build system cobbled together using bunch of bash scripts and simple Makefiles recursively combined.

How can I go about recreating the build system using a modern version of GNU make? (Or some other tool.)

The code base is large, split in to many sub-directories, and has non-trivial cross sub-folder dependencies and system library linking requirements.

Since I can build a debug-enabled set of executables using the current build system just fine, is there any way to introspect in to these files construct a fresh set of build and linking rules?

Thank you

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

往事风中埋 2024-12-03 19:41:01

没有任何魔法可以为您解开这个构建系统。清理它需要缓慢而仔细的工作(自然要一路测试)。

开始在 GNUMake 下运行 makefile(如果还没有的话)。逐步清理它们,合并它们,将bash脚本的功能吸收到其中。绘制这些“重要的跨子文件夹依赖关系”;了解 Make 如何处理依赖关系,当您觉得可以时,请尝试高级自动依赖关系生成 在一侧的沙箱中;一开始理解起来有点困难,但是一旦你开始使用它,你就会爱上它。

你可能会想不去管它。毕竟,构建系统按原样运行。问题在于它在史瓦西极限上摇摇欲坠。现在你就可以清理它了——这并不容易,但在你的能力范围之内。但如果你不这样做,对代码库的小改动将需要对构建系统进行小改动,总是添加,从不减少。构建系统的规模和复杂性都会增长,清理工作将逐渐变得更加困难,直到它超出你的视野,之后你将无法比它增长的速度更快地减少混乱(并且仍然做所有其他事情)你必须做的事情)。这是众所周知的反模式

There is no magic that will untangle this build system for you. Cleaning it up will take slow, careful work (testing all the way, naturally).

Start running your makefiles under GNUMake, if you don't already. Gradually clean them up, merge them, absorb the functions of the bash scripts into them. Chart these "non-trivial cross sub-folder dependencies"; see how Make handles dependencies, and when you feel up to it, try Advanced Auto-Dependency Generation in a sandbox off to one side; it's a little tricky to understand at first, but once you start using it you'll love it.

You may be tempted to just leave well enough alone. After all, the build system works as is. The trouble is that it is teetering on the Schwartzschild limit. Right now you can clean it up-- it won't be easy, but it'll be within your ability. But if you don't, small changes to the codebase will require small changes to the build system, always adding, never reducing. The build system will grow, in size and complication, the job of cleanup will gradually become more difficult until it passes beyond your horizon, after which you will not be able to reduce the mess faster than it grows (and still do all of the other stuff you have to do). This is a well-known anti-pattern.

勿挽旧人 2024-12-03 19:41:01

我用来让 GNU make 进行任何类型的内省的两种技术是:

  • 对于静态 GNU make 依赖性分析:将“-d -p”标志注入到
    现有(工作)制作流程,然后对输出进行后处理
    awk/sed/python 用于生成带有 graphviz/dot 输出的调用图。
  • 对于动态 GNU make 进程/目标分析:使用“make SHELL=~bin/make_introspect.sh”,它可以在 makefile 调用配方和 makefile 调用的边界处检测并发出记录(如命令行、目标、进程 ID、配方)其他 makefile

对于答案的一般性感到抱歉,到目前为止,我从未概括过这些技术,只是在特定项目中使用它们

The two techniques I've used to get GNU make to do any kind of introspection were:

  • for static GNU make dependency analysis: inject "-d -p" flags into
    existing (working) make processes, then post-process the output with
    awk/sed/python to generate call graphs with graphviz/dot output.
  • for dynamic GNU make process/target analysis: use "make SHELL=~bin/make_introspect.sh" which can detect and emit records (like command lines, targets, process IDs, recipes) at the boundaries where makefiles call recipes, and makefiles call other makefiles

Sorry for the general nature of the answer, so far I've never generalized those techniques just used them in specific projects

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文