Version 4 (modified by lou, 13 years ago) (diff)

Additional comments to go witih coin.m4 and attachments.

This page is for communicating features of the new BuildTools version 1.0

One this page we can share our thought on what should go into a new version of the BuildTools.

Technical Aspects

Use of newer autotools


  1. Autoconf 2.61 (currently 2.59). Advantages?
    (LH) Well, for one, it fixes an issue with the declaration of exit() that is pervasive across many basic autoconf tests which construct and compile short code fragments.
    Along the lines of Andreas' comment below about libtool, there are many comments in autoconf macros to the effect that cl support really needs some attention. Are we up for this? Might save time in the long run to get the changes we need into the autoconf source tree. Not to mention the warm fuzzy feeling of contributing back to autoconf.
  1. Automake 1.10 (currently 1.9.6). Advantages?
  1. Libtool stays at 1.5.22; nothing new has been released yet. However, that version has a number of bugs that we currently patch "by hand". Maybe we can use a new non-official version? All that is needed is really the libtool.m4 file, and we might be able to distribute a good working version together with BuildTools? This way, we can also easily suggest fixes to the Libtool developers and include their changes.

AW: I will start with this on my settings now, using Bonmin as the example. At some point I will also create a pseudo "CoinAll" project which we can use to test the new coin.m4 etc on.

LH: I've been using autoconf 2.61 across several platforms for about 10 days now, with no noticeable ill effects.

Creating libtool only once

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.

AW: I'm going to look into this.

LH: 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).

Avoiding aclocal.m4 creation

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.

AW: I'm going to look into this.

New or improved features

Different handling of DOS compilation

Lou's suggested handling of --enable-doscompile?

LH: I've attached versions of BuildTools/coin.m4 and CoinUtils/ which implement the --enable-doscompile idea for msvc (cl/link) and mingw (gcc/g++/ld with -mno-cygwin). If you omit --enable-doscompile, you'll get a standard cygwin build. Msys is missing; I don't have that environment to play with. The files also cope with absence of a Fortran compiler, as mentioned in the mailing list. These files expect to see autoconf 2.61.

Attachments (2)

Download all attachments as: .zip