[Coin-discuss] Finding libs at run time and Cbc/Dylp
lou at cs.sfu.ca
Wed Mar 29 16:25:40 EST 2006
<< Mike makes a bunch of observations and recommendations about the COIN
makefile structure. >>
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.
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. 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,
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.
It's a real pain to make a global change in optimisation level or library type.
(Yeah, you can write a shell script, but that's not a good answer.)
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.
Some, but not all, of this can be improved with autoconf, or similar.
Help me, TLC guys! I know you've been thinking about this, and I'm way
out on a limb putting words in your mouths :-). For the rest of you with
sufficient interest to follow this, now's the time to make your opinion heard.
More information about the Coin-discuss