有没有办法在 Makefile 中自动生成依赖关系树？
摘要问题： 我正在编写一个高度模块化的中型 C++/C 程序。它有一个通用接口，允许您插入具有相同函数声明但不同实现的多个不同源，并获得具有不同功能的可执行文件。
我正在制定一个可以处理构建职责的 make 系统。目前，它能够根据配置文件的内容（用于制作过程）获取专用源，并将它们转储到具有正确通用名称的临时文件夹中。现在，我只需编译该项目即可。
问题是我有数量可变的源，并且源所依赖的标头可能会随着各个实现的变化而变化。换句话说，静态 makefile 无法解决问题。
“1。” 单独使用 Makefile 系统，是否有某种方法可以自动生成 Main.cpp 需要编译的对象（.o）文件列表？
我知道我可以通过编写一个我的 makefile 调用的小 python 脚本来做到这一点，该脚本随后通过解析 c 文件并检查其依赖关系来创建自定义 makefile，从基本 Main.cpp 文件开始。
但如果有更标准化的解决方案或在 make 中执行此操作的某种方法，我不想转向这种黑客解决方案。
'2。'
如果 makefile 系统无法做到这一点，我应该继续使用自定义 python 脚本，还是有更优雅的解决方案？
............
为了完全清楚，我再次没有依赖项/源/标头/对象的恒定列表，并且我不想强迫我的最终用户维护这样的列表。
我需要某种方法根据我的 C 文件的内容自动生成这棵树。
如果这是一个“愚蠢”的问题，我很抱歉，我对 make 的世界相对较新——而且像大多数人一样是自学成才的。
谢谢你！
如有任何问题，请随时提出。
不过，仅供参考，我的项目有太多来源，无法将它们全部发布，而且出于专有/研究原因，我无法这样做。
Abstract question:
I'm programming a mid-size C++/C program that's highly modularized. It has a common interface, which allows you to drop in a number of different sources with the same function declarations, but different implementations and get executables with different functionalities.
I'm working out a make system that can handle the building responsibilities. Currently it's able to grab specialized sources based on contents of a configuration file (for the make process) and dump them in a temporary folder with the proper generic names. Now, I only have to compile the project.
The problem is I have a variable number of sources and the headers that the sources depend on can change with the individual implementations. In other words a static makefile won't do the trick.
'1.'
Using the Makefile system alone, is there some way to autogenerate the list of objects (.o) files that Main.cpp needs to compile?
I know I could do this by writing a little python script that my makefile calls, which subsequently makes a custom makefile by parsing the c-files examining their dependencies, starting with the base Main.cpp file.
But I didn't want to turn to this hackish solution if there was a more standardized solution or some way to do this within make.
'2.'
If the makefile system is incapable of this, should I go ahead with my custom python script, or is there a more elegant solution?
...............
To be perfectly clear, again I do NOT have a constant list of dependencies/sources/headers/objects and I do NOT want to force my end user to maintain such a list.
I need some way of autogenerate this tree, based on the contents of my C-files.
Apologies if this is a "dumb" question, I'm relatively new to the world of make -- and like most am self-taught.
Thank you!
Feel free to ask any questions.
FYI, though, my project has too many sources, though, to just post them all and I cannot do so for proprietary/research reasons.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，如果您使用的是 GCC！这是我当前项目中的一些 Makefile（对于所有实际用途，我会将其放在公共域下，玩得开心）。
如果我错过了什么，请告诉我，我会再次检查我的 Makefile。
请注意， $(OBJECTS) 是我想要在二进制文件中包含的对象列表，而 $(LOBJECTS) 是正在编译为静态存档的对象列表。 $(OBJECTS) 和 $(LIB) （由 $(LOBJECTS) 创建）然后被编译成最终的可执行文件。因此整个过程可以跨不同类型对象的多个构建工作，然后进行链接等。
哦，是的，请确保 您需要将空的
.d目录签入。您
mkdir .d否则它可能会失败。这里唯一需要注意的是 必须列出来源。但是，如果您愿意，您可以设置一些小工具来使用find来查找所有源。最后，这可能可以通过使用多个目标来整理以提高效率和可读性（
%.o .d/%d); 谢谢你的提醒。Yes, if you are using GCC! Here is some of a Makefile I have in a current project (for all real uses, I'll put this under public domain, have fun).
If I missed something let me know and I'll check my Makefile again.
Note that $(OBJECTS) is a list of objects I want in my binary and $(LOBJECTS) is a list of objects that is being compiled to a static archive. $(OBJECTS) and $(LIB) (which is created by $(LOBJECTS) are then compiled into a final executable. So the whole thing works across multiple builds of different types of objects followed by linking, etc.
Oh yeah, make sure that you
mkdir .dor else it will probably fail. You'll want to check in an empty.ddirectory to your version control.The only caveat here is that you have to list sources. However, if you want you could set up some little tool to use
findto find all your sources for you.Finally, this can probably be tidied up to be more efficient and more readable by using multiple targets (
%.o .d/%d); I'll have to look into that. Thanks for reminding me.简化构建的一种方法是跳过依赖项。每次都重新编译一切。只有当构建必须完成多次，或者需要“很长时间”时，其定义取决于使用，并且依赖关系发生很大变化，才有意义详细的依赖关系构建。
One way to simplify the build is skip dependencies. Just recompile everything every time. Only if the build has to be done many times, or it takes a "long time", the definition of which depends on the use, and the dependencies change a lot, does it make sense to do a detailed dependency build.