Re: [boost] Boost.Build changes for 1.38

Subject: Re: [boost] Boost.Build changes for 1.38
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-11-02 09:11:27

David Abrahams wrote:

> 
> on Sat Nov 01 2008, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
> 
>> As we're nearing 1.37, and the time for big changes that follows after,
>> I wanted to discuss one Boost.Build change I want to make.
>>
>> Right now, we have two ways to build Boost -- using bjam directly, and using
>> configure and make (which are wrappers over boost.build). The first approach
>> may be a bit hard, and the second is very nice when it works, but it leads to
>> other problems:
>>
>> - users start to assume it's "real" configure, and get upset when various
>> variables that CXXFLAGS have no effect
>> - if users want to do anything custom, like mingw cross compilation,
>> they have to go back to direct use of bjam anyway.
>>
>> So, I'd like to suggest a solution where building of boost involves three steps:
>>
>> 1. ./bootstrap.sh or ./bootstrap.bat
>> This step just builds bjam and puts it into boost root
>>
>> 2. ./bjam [--build-type=complete] [--layout=xxx] [properties] configure
>> This step:
>> - Tries to detect what compilers you have
>> - Figures which optional libraries you have, and which you don't (e.g. ICU)
>> - Writes a file project-config.jam with all the discovered information.
>>
>> 3. ./bjam
>> This step can be usually invoked with no parameters, reads the configuration
>> information
>> from project-config.jam, and builds everything.
>>
>> For new users, this solution is only marginally more complex that configure/make, and
>> does not create the false impression it's autoconf. For power users, the file produced
>> in (2) can be tweaked and extra options can be specified in (3). For all users,
>> this means that various properties can be specified only once in (2) and need not be
>> repeated on every build, which is clearly a convenient thing.
>>
>> Anybody has comments about this plan?
> 
> Yeah.  For a surprisingly large number of *nix users, if the
> process doesn't look like ./configure && make && make install, they will
> get upset.  

I am not so sure -- it is my feeling that any process that, in default case,
does not requires to manually specify anything, but just run 1, or 2, or 3
commands, will be fine with most folks.

> That's the reason the configure script was created.  Only a 
> small subset of those users may try to set CXXFLAGS et. al, and even a
> smaller subset needs to do cross-compilation, so I believe we're making
> more people happy than angry.  I would be very, very cautious about
> removing the configure script.

In any case, we can retain the configure script, but make it wrapper over
the above scheme, and also change the makefile to be exactly this:

        all:
                bjam
        install:
                bjam install

In this way, if something goes wrong and needs tweaking, I don't have to
resort to cumbersome "open Makefile, copy-paste the bjam invocation command,
and then..." kind of instructions.

- Volodya