From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-27 19:48:52
David Abrahams wrote:
> 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?
I think he was referring to doing multiple different directories where
you do a "configure" with different settings of compiler, and other
settings. Which is the way you work with more than one compiler and
>>tar xjvf package-0.0.tar.bz2
>>With bjam I found things a bit more difficult. Once I downloaded and built
>>bjam, to build boost I first made a shell script:
>>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.
But it's not any harder than the *real* autoconf equivalent of:
tar xjvf package-0.0.tar.bz2
###-haven't seen a configure script you can change which
###-python should be used
And I dare people to point more than one configure script, or configure
installation instructions that tell you that you can set GCC/CC etc. to
use something other than the system compiler.
>>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.
Well it will eventually.. I only recently convinced Volodya that having
those top level options everywhere was a good idea.
And, yes in BBv1 this is a hack :-)
>>* 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.
Although I haven't tried it, so don't know if it works.
>>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
> 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.
Here's a test for you to see how close we are to being there.. With the
latest Boost CVS state, make your user-config.jam have only this (which
will eventually be done by default):
import msvc-config ;
import cw-config ;
import pythong-config ;
And cd to boost-root and do:
bjam --v2 --with-thread install
And that's it. Which only leaves the install of bjam itself, but we can
work on that also.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk