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

Michael Hennebry hennebry at web.cs.ndsu.nodak.edu
Wed Mar 29 18:45:50 EST 2006


On Wed, 29 Mar 2006, Lou Hafer wrote and MH edited some long lines:

> 	Good points.  I think it's generally true for the core projects (Coin,
> Osi, Clp, Cbc, Cgl) that there are separate targets for libraries and
> executables.  Might not be universal, but that's the direction we're heading.

Good.

> 	I'd argue that the question of whether dependent builds should be
> triggered automatically is more philosophical than technical.  Make is really
> pretty good at picking off circular dependencies, where they exist.

Make can't readily notice circular
dependencies when they arise from sub-makes.

> For COIN, I
> think the problem is not circularity, but repeated traversal of the dependent
> subtrees,
> as each project makes sure that all the libraries it needs are indeed
> present.  Annoys the hell out of me, but I can't seem to persuade make to shut
> up about it.
>
> 	That said, I lean in favour of automatic builds for dependencies.  When
> it works well,
> it means that I can fire off a build and go get a cup of coffee,

"When it works well".
This, I suspect, is the key difference between us.
The difference is between convenient use of something that is expected
to work and the ability to slog through the mess if it doesn't.
This one has had little joy from other people's make files.
He hasn't had much joy from his own make files either,
but fixing something small that one has written oneself
tends to be easier than deciphering something huge written in Linear A.

> instead of watching for aborts and typing more commands.
> I assume that for much
> of the user community, the more automation in the build process, the better.
>
> 	One can also argue the idea of having independent settings for OptLevel
> and LibType in each makefile.  It's really nice to have fine-grained control.

One could, but this one won't.
The way to do it is with global settings that can be overridden locally.
Documentation is important.

While on the subject of OptLevel, let me remind make
file writers again that -g is not an optimization level.

> 	Combine the above two issues (automatic triggering of builds, and option
> settings) and things get really complicated.
> I've been juggling this with dylp,
> which has several compile-time options.

With regard to automatic triggering of builds,
it's possible to have it both ways.
Add a target named dependencies.
Nothing would depend on it,
but its output might be needed by executables in the module.
A user who wanted to go for coffee would type something like
make dependencies executables
The executables target would depend on local libraries.
The dependencies target would make any foreign libraries needed.
Those of us who aren't allowed coffee while trying to build coin
stuff for fear that we might give the computer a drink, can type
make libraries
in all the necessary directories,
followed by
make executables
in all the necessary directories.

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