Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk