[Cbc-tickets] [BuildTools] #95: upgrade to newer autotools version
BuildTools
coin-trac at coin-or.org
Sat Dec 14 12:00:56 EST 2013
#95: upgrade to newer autotools version
------------------------+---------------------------
Reporter: stefan | Owner: stefan
Type: enhancement | Status: assigned
Priority: major | Component: build system
Version: trunk | Resolution:
Keywords: |
------------------------+---------------------------
Comment (by stefan):
I like the mechanism of being able to configure all in one rush (the
argument that you don't want configure to fail for the last project after
having build all-but-the-last one convinced me).
Still building one project against installed versions of its dependencies
sounds cleaner to me than what is happening now (we could also get rid of
the -D<PRJCT>_BUILD compiler flag again).
However, requesting root permissions for a make (all) isn't that nice,
indeed. I hadn't thought about this before. But the DESTDIR sounds like a
viable alternative.
So do I understand correctly that proposal idea B is to configure all
projects, using the usual configure-style recursion, then do make and make
install in each project. If $prefix is not writable, then we do make
install into a writable DESTDIR. If we used DESTDIR, then the make install
at the toplevel will copy DESTDIR into $prefix (assuming user used sudo
now), otherwise nothing needs to happen there.
Or should we use DESTDIR in any case, so things are put into $prefix only
if a user said make install. Maybe he actually does not want to install
and he wouldn't think about having to call make uninstall if he did not do
make install explicitly.
I haven't thought much about make test, but as far as I see it wouldn't
change much.
If we build against installed projects (either in $DESTDIR or $prefix),
there isn't much work left to do for pkg-config. The main task is to find
out which projects are actually present at configure time. Since
dependencies have not been build&installed then, looking only for a
library or header file will not be sufficient. The configure of a project
like Osi will have to look for both !CoinUtilsConfig.h and !../CoinUtils/
to see if an installed or to-be-build-and-installed version of !CoinUtils
is present. pkg-config would still simplify this.
If we first build&install dependencies (into DESTDIR), then I guess the
*-uninstalled.pc file will have to point to DESTDIR/$prefix, while the
other *.pc files have to point to $prefix only? Or it would be just one
.pc file and we pass in the DESTDIR via {{{--define-
variable=DESTDIR=$DESTDIR}}} when appropriate? (but how to know that? --
maybe not a good idea)
Symlinking the *-uninstalled.pc files in the toplevel build dir sounds
like a viable option.
Maybe every project can put a symlink for its own prjct-uninstalled.pc
there when finishing configure?
Oh, and the _DEPENDENCIES should indeed only matter if one builds static
libs. I wouldn't worry too much about it for now.
--
Ticket URL: <https://projects.coin-or.org/BuildTools/ticket/95#comment:25>
BuildTools <http://projects.coin-or.org/BuildTools>
Tools for configuring and compiling COIN-OR codes
More information about the Cbc-tickets
mailing list