What's the point of this makefile architecture?

Question

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?

Answer 1

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).

Answer 2

I would say for me smells like a bootstrapping process...