From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-04 19:27:12
----- Original Message -----
From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
For the convenience of users, the implementation has been in the
> header file only. Currently, no general build system for boost is
> available, thus individual libraries need to spend great effort
> to provide a build system when they use .cpp files for implementation.
> See the regex library as an example. I've avoided the effort so
> far.
We've been beating on Jam (www.perforce.com/jam/jam.html) at work, in the
hopes of creating a really easy-to-use system that can cover lots of
compilers and platforms. So far, we think it is probably able to do the job.
I think that when we've got something working we'll be able to contribute it
to boost.
Jam does have a few distasteful limitations, but we don't know of a better
alternative right now. It's possible that if I understood Cons or (the
vaporware) ScCons better, I'd prefer them, but from what I understand of
these systems I like the basic structure of Jam better. Jam has its own
interpreted language built-in; I'm pretty sure I'd prefer Python for this
purpose. As far as I remember, the boost membership has spoken on that
count, and has rejected the idea of using a tool that brings along anything
that big.
One idea I've been pursuing is to have a special target per compiler whose
build action simply invokes that compiler without arguments (or in the case
of gcc, "gcc -v") to check that it exists in the system. Because Jam will
not try to build a target if any target it depends on has failed to build,
I'm hoping to make compiler-specific builds depend on the special compiler
target. That way, regression tests won't even try to build for missing
compilers.
Regards to all,
Dave