Re: [boost] building shared boost libraries

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 21:30:54

----- Original Message -----
From: "Timothy M. Shead" <tshead_at_[hidden]>

>  > If it does everything so well, why do people use
>  > other tools? I just want to get a balanced sense of its place in the
world.
>
> What other tools?  I'd never heard of Jam until looking at the boost
> source a few days ago, and Jam doesn't provide near the functionality -

Oh, I realize Jam is a fringe case, but most developers I know are using a
mix of hand-tuned makefiles and shell scripts, or cons, or the like.

> it's fair to say that autoconf/automake/libtool is a complex solution to
> a complex problem; with an autotools-based build, I can do
>
> $ make distcheck
>
> and sit back while the tools create a distribution archive in one
> directory, unpack it into a second, cross-compile it into a third, and
> run regression tests on the results, leaving me with a very high level
> of confidence that the archive is complete and will compile for other
> people.  If I give you that archive, you can do
>
> $ ./configure
> $ make distcheck
>
> and do the whole thing on your machine.

Boost.Build isn't targeted primarily at people who want to do a
configure/build/install in two keystrokes; it's primarily for developers who
need to go through the compile/edit/debug/test cycle on multiple compilers
with multiple configurations (e.g. debug, release, profiling, debug with
python memory debugging...), etc. We do believe that if we can do all of
that well, we will also be able to handle the installation problem with
little effort, but I think the target audience is really different

> Just about the only argument I
> can think of against using autotools for boost is that the average
> Windows installation doesn't have the environment necessary to run it.

Have you read our build system criteria?

http://www.boost.org/tools/build/build_system.htm#design_criteria

Are there still no reasons to use Boost.Build (and this part is important:)
from the point-of-view of the needs it's trying to satisfy?

Here's an extreme example handled by Boost.Build that should test how well
libtool satisfies some of our needs: If I want to create a project that
builds and tests python modules using KCC, GCC, and one other compiler all
at once on several platforms using libtool, how much work would it be?

-Dave