What's the point of this makefile architecture?
I have a program that I am trying to compile, let's call it P. P needs a third party library, L1. L1 needs another library, L2. So far, there is nothing strange.
The Makefile for P basically just sets some variables and then includes the makefile for L1.
The make file for L1 runs a whole bunch of variables and stuff (including the list of files to compile, for example) and then includes the L2 makefile.
L2s makefile does the whole job and actually does 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 cannot use them because the L2 makefile does all the work.
Also, if you compile with dynamic libraries, it will look for libraries to load in your compile directory at runtime, which is not where they belong on the production system.
My question is, why the hell did they design it this way?
source to share
It looks like something that has grown organically:
- Someone wrote an L2 Makefile and made it very complex and powerful. This Makefile takes variables such as lists of objects and builds them from where they start (for example, nothing).
- Someone (else?) Had to write an L1 Makefile and decided to piggyback by building L1 lists and then passing everything to the L2 Makefile rather than trying to invent all these mechanisms.
- Someone in your store had to write a P Makefile and copy the L1 Makefile.
The problem with this design (besides being difficult to untangle) is that it is only as good as the worst Makefile in the chain (possibly made by someone else). If L2 doesn't compile, then some Makefile includes a delicate Makefile and breaks it, otherwise something in the environment has changed, as one of the early authors hoped for. If the L2 Makefile handles dependencies correctly, you should be able to convince it to use the libraries without rebuilding them (and you can try L2 yourself to diagnose the problem). If it isn't, then you just need to go for spelunking.
source to share