这个 makefile 架构有什么意义？
我有一个正在尝试编译的程序，我们称之为 P。P 需要一个第三方库，L1。 L1 需要另一个库，L2。到目前为止，没有什么是奇怪的。
P 的 Makefile 基本上只是设置一些变量，然后包含 L1 的 makefile。
L1 的 makefile 执行一大堆变量设置和内容（例如，包括要编译的文件列表），然后包含 L2 的 makefile。
L2s makefile 做了很多工作，实际上完成了所有 3 个工作。
我的问题是 L2 不想编译。
但是，我的系统已经有两个库的二进制版本，但我无法使用它们，因为 L2 makefile 完成了所有工作。
此外，如果您使用动态库进行编译，它将在运行时在您的编译目录中查找要加载的库，这不是它们在生产系统上的位置。
我的问题是：他们到底为什么要这样设计？
I have a program I'm trying to compile, lets call it P. P needs a 3rd party library, L1. L1 needs another library, L2. So far, nothing is that weird.
The Makefile for P basically just sets some variables, and then includes the makefile for L1.
The makefile for L1 does a whole bunch of variable setting and stuff, (including a list of files to compile, for example) and then includes L2's makefile.
L2s makefile does a whole LOT of work and actually makes all 3.
My problem is that L2 doesn't want to compile.
However, I already HAVE a binary version of both libraries for my system, but I can't use them because the L2 makefile does all of the work.
Also, if you compile with dynamic libraries, it's going to look for the libraries to load in your compile directory, at runtime, which isn't where they belong on the production system.
My question is: Why the heck did they design it this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能是因为他们维护库和程序 - 对于他们来说，编译工作并且通过这样做，他们可以保证两个库都是最新的（因此程序具有最新的代码可以使用）。
Probably because they maintain both libraries and the program - and for them, the compilations work and by doing it this way, they are guaranteed that both libraries are fully up to date (and hence that the program has the latest code to use).
在我看来，这就像有机增长的东西：
这种设计的问题（除了它很难理清之外）是它只能与链中最差的 Makefile 一样好（可能是其他人制作的）。如果 L2 没有编译，那么要么某些 Makefile 包含了一个脆弱的 Makefile 并破坏了它，要么环境中的某些内容发生了早期作者之一所期望的更改。如果 L2 Makefile 正确处理依赖关系，那么您应该能够说服它使用库而不重建它们（并且您可以尝试单独创建 L2 来诊断问题）。如果没有，那么你就只能去洞穴探险了。
This looks to me like something that grew organically:
The trouble with this design (apart from its being hard to untangle) is that it's only as good as the worst Makefile in the chain (probably made by someone else). If L2 isn't compiling, then either some Makefile has included a delicate Makefile and broken it, or else something in the environment has changed that one of the earlier writers counted on. If the L2 Makefile handles dependencies correctly, then you should be able to persuade it to use the libraries without rebuilding them (and you can try making L2 alone to diagnose the problem). If it doesn't, then you'll just have to go spelunking.
我想说对我来说闻起来像是一个引导过程......
I would say for me smells like a bootstrapping process...