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

Michael Hennebry hennebry at web.cs.ndsu.nodak.edu
Wed Mar 29 12:56:02 EST 2006


On Tue, 28 Mar 2006, Lou Hafer wrote:

> In Examples/BAC/Makefile, you have the lines
>
> default: bc
>
> bc : libdepend
>         ${MAKE} -f Makefile.bc bcps
>
> libdepend:
>         (cd $(CoinDir)/Osi/OsiClp && ${MAKE} install)
>         (cd $(CoinDir)/Cgl && ${MAKE} install)

> 	We should probably be asking some global questions, though. The current
> usage of Makefile.coin and Makefile.location needs to be looked at with a
> critical eye.

I question the desirability of having one module make a sibling,
especially if they are maintained by different people.
If a making a module requires a currently unmade module,
the make should complain and bugger out.
Making a COIN module can be all too interesting
without having the make of one module reaching
out to affect all the others.
In the most likely non-fatal case,
an unexpected make will happen before one has done any
of the adjusting one would otherwise have done for it.
Fatal cases are a mess.

It's been a while since I've maked any COIN stuff,
so maybe this has been done already:
Have separate targets for things that require linking,
i.e. executables, and those that do not, e.g. libraries.
That will break most circular dependencies.
That will make it cleaner to build things that both
use and are used by the Osi interface.
Building libraries will only require foreign header files.
Once all the libraries are built,
they are available to link with executables.
With separate targets for libraries and executables,
finding a good build order is much easier.
Build all libraries before building any executables.
To this end,
the default target of a make file should not be all.
It should be one that complains that you did not specify
whether to build libraries or executables.

-- 
Mike   hennebry at web.cs.ndsu.NoDak.edu
"Demons after money?
Whatever happened to the still-beating heart of a virgin?
No one has any standards any more."                    --  Rupert Giles




More information about the Coin-discuss mailing list