这个makefile架构有什么意义？

Question

我有一个我正在尝试编译的程序，我们称之为P. P需要第三方库，L1。 L1需要另一个库L2。到目前为止，没有什么是奇怪的。

P的Makefile基本上只设置了一些变量，然后包含了L1的makefile。

L1的makefile执行一大堆变量设置和填充（例如，包括要编译的文件列表），然后包含L2的makefile。

L2s makefile完成了很多工作，实际上完成了所有3个工作。

我的问题是L2不想编译。

但是，我已经为我的系统安装了两个库的二进制版本，但我不能使用它们，因为L2 makefile可以完成所有工作。

此外，如果使用动态库进行编译，它将在运行时查找要在编译目录中加载的库，这不是它们在生产系统中的位置。

我的问题是：为什么他们这样设计呢？

Answer 1

可能是因为它们维护了库和程序 - 对于它们来说，编译工作并通过这种方式，它们保证两个库都是完全最新的（因此程序具有最新的代码使用）。

Answer 2

这让我看起来像是有机增长的东西：

1. 有人写了L2的Makefile，使它变得非常复杂和强大。这个Makefile使用变量，例如对象列表，并从它们开始的任何东西（比如说，什么都没有）构建它们。
2. 有人（否则？）必须编写L1的Makefile并决定通过构建L1的列表然后将所有内容交给L2的Makefile来搭载，而不是试图重新发明所有的机制。
3. 你店里的某个人必须写下P的Makefile并捎带在L1的Makefile上。

这种设计的问题（除了难以解开之外）是它与链中最差的Makefile（可能由其他人制作）一样好。如果L2没有编译，那么一些Makefile包含了一个精致的Makefile并将其打破，或者环境中的某些东西已经改变了，其中一个早期的作者依赖。如果L2 Makefile正确处理依赖关系，那么你应该能够说服它使用库而不重建它们（你可以尝试单独使用L2来诊断问题）。如果没有，那么你只需要进行探险。

Answer 3

我会说对我来说闻起来像是一个引导过程......