From: Beman Dawes (beman_at_[hidden])
Date: 2001-01-09 13:22:07
There has been a lot of evolution recently in my thinking about adding
boost library build support. The requirements seem to me to be:
* A developer adding a new library must at most add only a single entry to
a text file, and not have to know anything about platform specific
files. If possible, a newly added library should be automatically
detected, so that the developer doesn't need to do anything at all beyond
using the boost directory structure.
* A developer adding support for a new platform or compiler should only
have to add to a single file describing how to do the build for that
platform or compiler, and shouldn't have to identify the files that will
need to be built.
* The build should rely only on tools native to the platform and compiler,
or supplied via the boost download. (Thus ScCons isn't a solution, even if
was available, because it requires Python be installed.)
* The details of how the build is done for a particular platform or
compiler should be appropriate for that platform. Thus there might be a
supplied make file, an IDE configuration file, or whatever suits.
* The requirements above imply some new automated tool. Jens Maurer's
regression.cpp has shown that such a tool (with separate file and command
configuration) can be kept very simple yet effective.
* Platform and compiler specific build files can and should be
pre-generated and supplied as part of the download to minimize user effort.
* Some users wish to build libraries form multiple platforms or
compilers. It is easier to supply all build files and let the user choose
which to invoke.
* The build tools must be able to handle Boost growth issues such as
identified in Directory Structure proposals and discussion.
(Thanks to John Maddock for private discussions regarding several of these
I've built a generator program (booster.cpp, using some of Jens' code)
which can take in configuration files and produce an output file such as a
script, or makefile, or anything else requiring text subsitution.
In addition to the program, there are two configuration files (one
specifying the file list, the other specifying the operations to be
performed and text to be operated upon.
There is also an output file (sunpro.mak) which is the result of executing:
booster -c=sunpro.cfg make path=../..
I'm not claiming this would actually be a valid Sunpro make file; I just
used the regex sunpro.mak as a model because it was shortest.
Pending comments, I'll go ahead and try to actually produce build scripts
for one or two of the compilers I have access to.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk