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

BuildTools coin-trac at coin-or.org
Sun Dec 15 06:37:43 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 kelman):

 I'm not positive exactly how -D<PRJCT>_BUILD works right now, don't know
 about that.

 If we put back AC_COIN_MAIN_PACKAGEDIR (it's pretty harmless, standalone,
 and does what we want regarding --with-<prjct>, COIN_SKIP_PROJECTS, etc.)
 then normal autoconf recursive configure will populate $subdirs (lower
 case) with the appropriate subprojects at the top level.

 The question is whether or not to then, in the top-level Makefile.am, set
 `SUBDIRS = $(subdirs)`. Setting upper-case SUBDIRS for automake gives us
 the present recursive make behavior, but typically recursive `make all` of
 everything first, then recursive `make install` of everything. We could
 continue doing this but add additional make rules to enforce make install
 of dependencies into DESTDIR before make all of larger projects (I think I
 like the uniformity of always doing the same thing - and since most of
 make install is just copying files I don't think we would need to rewrite
 it to manually copy from DESTDIR to $prefix). Or we could leave upper-case
 SUBDIRS unset, so automake doesn't create any recursive make targets,
 instead we would put them together ourselves.

 make test is already manually written, I doubt it would need to change at
 all. The difference is whether or not we'd have to manually write
 recursive all, install, clean, distclean, uninstall, etc rules ourselves
 or let automake create them.

 I don't see Osi ever checking for !CoinUtils headers, I only see that
 happening for !ThirdParty projects where it isn't known whether the user
 actually has the source. For the internal COIN projects, I see either pkg-
 config or AC_COIN_CHECK_PACKAGE_FALLBACK looking for the .pc files to
 determine existence of the dependency projects.

 There's a bit of difference here between the !CoinUtils subfolder of
 !CoinUtils, and the !CoinUtils subfolder of bigger projects that depend on
 it. The former doesn't need to worry about this installation/DESTDIR
 stuff. But we'd like to come up with a mechanism that would work for both
 (maybe that's just doing it redundantly on the small projects even when
 it's not necessary). I think we'll need to look at other projects to
 figure out how they do it - when you install into DESTDIR, do the .pc
 files get modified to take that into account?

--
Ticket URL: <https://projects.coin-or.org/BuildTools/ticket/95#comment:26>
BuildTools <http://projects.coin-or.org/BuildTools>
Tools for configuring and compiling COIN-OR codes



More information about the BuildTools-tickets mailing list