nick@ilm.com (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