[Cbc-tickets] [BuildTools] #95: upgrade to newer autotools version

[BuildTools]

#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