Re: [boost] Re: Boost to the rescue

From: Nick Rasmussen (nick_at_[hidden])
Date: 2005-04-18 14:07:09

On Mon, 18 Apr 2005, Rene Rivera wrote:

> Walter Landry wrote:
> >Rene Rivera <grafik.list_at_[hidden]> wrote:
> 
> >>1. Nobody has volunteered the time and expertise to support such a system.
> >
> >You must have missed the enormous flamewars when people suggested
> >using autoconf.  For example
> >
> >  http://lists.boost.org/MailArchives/boost/msg25583.php
> 
> No I didn't didn't miss it. And if you had read that thread you would 
> have seen my replies in that thread for example:
> 
> http://article.gmane.org/gmane.comp.lib.boost.devel/63354
> 
> >Given the response, I am not surprised that there is no autoconf
> >support in Boost.
> 
> Is that "not surprised" because of my response or the thread you referenced?
> 
> >>2. Such a system would be unusable to Boost developers which have to
> >>work with a variety of compilers and systems, usually at the same
> >>time.  Hence it would be a user only UI; so there is less incentive
> >>to support something like autoconf.
> >
> >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:

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 $*

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, modify the script to use those settings
instead and then call the script from the test directory, and also set
the BOOST_ROOT variable.  Again, it could just be inexperience and perhaps
there's an easier way,  but if there is it's not documented well.

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

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]

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

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

* 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, 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, 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.

-nick