On Mon, 18 Apr 2005, Rene Rivera wrote:
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> 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
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