这个makefile架构有什么意义?

时间:2009-09-15 19:11:39

标签: makefile

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

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

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

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

我的问题是L2不想编译。

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

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

我的问题是:为什么他们这样设计呢?

3 个答案:

答案 0 :(得分:2)

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

答案 1 :(得分:1)

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

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

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

答案 2 :(得分:0)

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