[Coin-discuss] Finding libs at run time and Cbc/Dylp

[Lou Hafer]

Francois,

	The first few lines of Cgl/Makefile, after the opening comments, are:
	
export CoinDir := $(shell cd ..; pwd)
export MakefileDir := $(CoinDir)/Makefiles
include ${MakefileDir}/Makefile.coin
include ${MakefileDir}/Makefile.location

Both Makefile.Linux and Makefile.location are included by Makefile.coin (look 
for Makefile.${UNAME} around line 44 of Makefile.coin). This is why you see an
error using the procedure you outline (add junk, etc.)

	Makefile.location is then included a second time.  And this same
sequence will repeat in Makefile.Cgl.  This is one of the things that makes me
say that it's time to have a global look at the make structure.  My guess (keep
in mind I'm reverse engineering history, always a dangerous pastime) is that
this amount of redundancy is just the result of makefile evolution.  Happens in
any sufficiently large body of code unless one occasionally steps back and does
a global analysis and rewrite.  (With the attendant danger of introducing new
`features'.)

	Does adding `LibType ?= SHARED' in Makefile.Linux pose a potential
problem?  Sure.  But in context, it's unlikely.  The top-level makefile is
usually just coordinating the build.  The heavy work is done by the subsidiary
makefiles.  If you want a static build for Cgl, you set LibType := STATIC in
Makefile.Cgl, which is responsible for actually building and installing libCgl.
(More on this whole philosophy in the reply to Mike Hennebry, coming next.)

	Arguably, where the BAC build goes awry is when it specifies
	
(cd $(CoinDir)/Cgl && ${MAKE} install)

By the normal COIN makefile conventions, this should be

(cd $(CoinDir)/Cgl && ${MAKE} -f Makefile.Cgl install)

But this doesn't get you the dependencies --- those are controlled from
Cgl/Makefile.
	
							Lou