[boost] Re: Boost to the rescue

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-27 16:45:55

nick_at_[hidden] (Nick Rasmussen) writes:

> On Mon, 18 Apr 2005, Rene Rivera wrote:
>
>> Walter Landry wrote:
>>
>> >You are confusing me.  The whole point of autoconf is to deal with
>> >a variety of compilers and systems.
>> 
>> Autoconf is about dealing with *one* compiler and *one*
>> system. Boost developers often switch between compilers, and
>> sometimes compile for multiple compilers at the same time. That is
>> something that is cumbersome to do with autoconf.
>
> Having always used autoconf for my projects, I don't really find
> having multiple build roots cumbersome, and use separate build roots
> for every package that I build, and every project that I work on:

How did "multiple build roots" come into this?

>
> tar xjvf package-0.0.tar.bz2
> mkdir build-PLATFORM
> cd build-PLATFORM
> ../package-0.0/configure <options>
> make
> make install
>
> With bjam I found things a bit more difficult. Once I downloaded and built
> bjam, to build boost I first made a shell script:
>
> #!/bin/sh -x
> bjam --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 \
>      --builddir=build-SUSE_IA32-gcc400pre1 --with-python-root=/usr \
>      -sPYTHON_VERSION=2.3 -sGCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc \
>      -sGXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ --layout=system $*

I agree that's too hard.

> and use that shell script to build from the toplevel directory.
> Figuring out all the settings to use a different compiler and python
> version took a bit of work the first time, but I just chalked that
> up to inexperience with bjam.  Whenever I needed to build boost for
> another platform, I'd just copy that script, change the variables
> and rebuild.

> The part where I ran into difficulty was when I tried to build the
> python testsuite as I was trying test the python docstring handling
> fixes.  I couldn't figure out what the right target was to build it
> from the root, and trying to build in the python test directory I
> discovered that the -- options were only supported in the toplevel
> jamfile, and I ended up having to read through the jamfile to find
> out what the -- options mapped onto in terms of bjam settings,

That's because in BBv1 the -- options are a hack used to make things
easy for people installing from the top layer.  BBv2 should make this
pain go away.

> With autoconf, once you run configure, everything autoconf
> auto-detects and everything you specify is baked into the Makefiles
> (and your configure line logged to config.status) in your build
> root, and in the case above, all I would have had to do is:
>
> cd libs/python/test; make

Yes.  Autoconf is a lot better for the build-to-install user.  For the
multi-platform/multi-compiler developer it's not so great.

> Other things that I'm sure are there with bjam but that I haven't
> had time to figure out:
>
> * parallel building 
>   e.g. make -j [number]

bjam -j [number]

> * build a particular directory
>   e.g. make -C <directory>

cd <directory> && bjam

> * stopping at the first error
>   bjam by default seems to do the equivalent of make -k

I think that's correct.  I don't think there's an option for that one.

> * making bjam feel/be faster 
>   It takes about 15 seconds on my box for bjam just to gather the
>   target list, before it even tries to update any targets.  With
>   my gcc build, a full traverse of all the directories takes about
>   two seconds.  I know it's not apples to apples, as boost
>   undoubtedly has a greater of header dependencies to check, 

It's not the header dependencies that slow it down.  BBv2 is much
faster than BBv1.

>   but
>   if we're just looking at targets that get built there's 985
>   files that were built in my boost build directory and 1228
>   in my gcc build directory.
>
> I'm sure all my problems with bjam are just unfamiliarity, 

No, not even most of them.

> and I'm also sure that bjam has benefits over a make-based system
> that I don't see, but on the whole all I really care about as far as
> build systems go is unobtrusiveness.  In that regard, autoconf based
> systems are the winner for me due to their familiarity, consistency
> and pervasiveness.

They work great on Unix for certain kinds of jobs.  They don't work so
well on Windows.  They're better for users and worse for developers
that don't know how to write autoconf internals.  I think we can make
Boost.Build easier to learn and use than autoconf is, but I have to
admit that it's not a hands-down win yet.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com