Changes between Version 6 and Version 7 of devel-pre-1.0


Ignore:
Timestamp:
Dec 16, 2006 1:07:00 AM (15 years ago)
Author:
lou
Comment:

Updating to reflect testing of libtool reuse.

Legend:

Unmodified
Added
Removed
Modified
  • devel-pre-1.0

    v6 v7  
    2121LH: I've been using autoconf 2.61 across several platforms for about 10 days now, with no noticeable ill effects.
    2222
    23 KM: Given some of the unrest among project managers recently I think we should go very SLOWLY about requiring a new set of auto tools. Unless there are significant advantages (and there may be) to using new versions I would vote to make BuildTools 1.0 compatible with 2.59, 1.9.6 etc. 
     23KM: Given some of the unrest among project managers recently I think we should go very SLOWLY about requiring a new set of auto tools. Unless there are significant advantages (and there may be) to using new versions I would vote to make !BuildTools 1.0 compatible with 2.59, 1.9.6 etc. 
    2424
    25 === Creating libtool only once ===
     25=== Creating libtool only once (libtool reuse) ===
    2626
    27 At the moment, the libtool script is created for every subprojects, and those annoying timeconsuming tests are run many times.  It should be possible to change that so that the libtool script is created only once in the packages base directory.
     27At the moment, the libtool script is created for every subprojects, and those annoying timeconsuming tests are run many times.  It should be possible to change that so that the libtool script is created only once in the package's base directory.
    2828
    2929AW: I'm going to look into this.
     
    3131LH: Some care is required. We need to get our compilers and compilation flags set correctly before calling COIN_INIT_AUTOTOOLS, else various macros down in the guts of autotools will 'help' us by providing defaults which are often incorrect (particularly in non-GCC environments).
    3232
    33 AW: I did a first attempt of this - it is now in BuildTools/trunk (not yet in devel-pre-1.0).  We using it with Bonmin, and it seems to work Ok, also on Cygwin.  What I did when the libtool script is NOT created (and the tests are skipped), I still read the values of come autoconf output variables and a few #define's from the config.status file in the directory where the libtool script is.
     33AW: I did a first attempt of this - it is now in !BuildTools/trunk (not yet in devel-pre-1.0).  We using it with Bonmin, and it seems to work Ok, also on Cygwin.  What I did when the libtool script is NOT created (and the tests are skipped), I still read the values of come autoconf output variables and a few #define's from the config.status file in the directory where the libtool script is.
     34
     35LH: This is working really well. The basic idea has held up well across all the platforms I've tested. I ended up adding one additional pair of variables to the set Andreas selected from config.status to get it to work in a Solaris/GCC environment. There's a potential 'gotcha' with a format change in config.status moving up to autoconf 2.61. Details in a series of
     36[http://list.coin-or.org/pipermail/buildtools/2006-December/000028.html posts on the buildtools list].
    3437
    3538=== Avoiding aclocal.m4 creation ===
    3639
    37 At the moment, we create a aclocal.m4 file in maintainer mode, that combines libtool.m4 and our coin.m4.  Instead, we can probably use the -I flag for aclocal.  Also, we think about disaggregating coin.m4 into different files, if the tests are truely in dependent.
     40At the moment, we create a aclocal.m4 file in maintainer mode, that combines libtool.m4 and our coin.m4.  Instead, we can probably use the -I flag for aclocal.  Also, we think about disaggregating coin.m4 into different files, if the tests are truly independent.
    3841
    3942AW: I'm going to look into this.
     
    4851
    4952AW: I saw in the proposed implementation that --enable-discompile can be given different arguments.  But I think we need to use a --with- configure argument for that?  (--enable- is only yes or no...?)
     53
     54LH: --with is fine by me, I just want the functionality. I've done a reimplementation that fixes up CPPFLAGS (really the critical point for -mno-cygwin) and works with autoconf 2.59 --- it's in the coin.m4 in a tar file attached to [http://list.coin-or.org/pipermail/buildtools/2006-December/000031.html this buildtool post]. I should check this page more often, I'd have changed --enable to --with while I was at it.