[BuildTools] Revised run_autotools script
Lou Hafer
lou at cs.sfu.ca
Fri Jun 11 20:19:56 EDT 2010
Folks,
To match the change towards more independent packaging for projects,
I've posted a substantially revised run_autotools script to BuildTools/trunk.
It should work with the old packaging configuration (a top-level package that
pulls in externals; tested with Coin-All) and the new (`split') packaging
configuration (which allows much more freedom; tested with the configuration I'm
currently using; see below).
There are a few changes you should be aware of, even if you're not yet
using the split configuration:
* The script decides whether or not to run the autotools in a given directory
based on whether the configure.ac file contains any macros with the prefix
AC_COIN_ But really, it just looks for that string. If you need to fool it
for some reason, add a comment containing AC_COIN_
* Directories given on the command line are now processed recursively. In the
previous script they were not. I think the change in the previous item
makes this change a feature and not a bug.
For those of you working with the split configuration, what you get is
much more freedom to move project code around. You can completely eliminate
duplicate checkouts, if you so choose. For example, the structure that I'm
currently using puts BuildTools, all `normal' projects, and individual
ThirdParty projects at the same level, while lumping Data projects into a Data
subdirectory. Everything is checked out with --ignore-externals, hence no more
duplication of code subtrees in every package.
If you're so inclined, pretty much anything currently pulled in as an
external can be treated as an independent unit (possibly after a bit of editing
of Makefile.am's). There are comments in the script with a bit more explanation.
Roughly, executing run_autotools in a directory pulls in the configuration
scripts required to make it an independent unit. Being an independent unit does
not preclude use as an external. Mostly this affects ThirdParty projects (Blas,
Lapack, Glpk, etc). The ability to handle BuildTools as an independent unit
affects all projects.
Give it a spin, if you're so inclined, and let me know of problems. If
you need the previous version, try BuildTools/stable/0.6.
Lou
More information about the BuildTools
mailing list