Re: [boost] building shared boost libraries

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-01-19 18:34:16

On Mon, Jan 14, 2002 at 09:30:54PM -0500, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Timothy M. Shead" <tshead_at_[hidden]>

> 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

Yes.  In fact, there are three audiences: (1) the authors of boost,
(2) installers of boost, and (3) users of boost.

> > 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?

I've read the criteria.  They sound like they were written for Jam. :-)

The odd criterion in the Boost.Build list of requirements is 

  The build should rely only on tools native to the platform and
  compiler, or supplied via the boost download.

Clearly that is a good idea for audience (2) and (3).  It is a bit
limiting (IMHO) to require it for boost developers.  In essence, it
forces you to reimplement wheels that have already been at least
partially invented.  However, I'm not about to say what you ought
to do with your time ;-)

For me, the main thing is that I can get shared libs built
with proper SONAMES.  As far as I can see, it involves tweaking
the jam files some.  If someone has already done this, please let
me know where and what to change.  Thanks.

> 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?

Recall that Timothy was talking about the whole of autotools.  Jam is
comparable to the suite autoconf/automake/libtool, not libtool alone.
Libtool is just the linker.

If you want to re-ask the question with the whole autotools suite, I
would answer that it can be done with a 20-line shell script.
Roughly, you do "mkdir $toolset; cd $toolset; ../configure
$toolset_options; make check" for each toolset.

But Boost has spent considerable energy moving away from autotools
towards Jam, so I'm sure noone is interested in a detailed comparison
of the two.

-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants