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-03 03:50:37

Johan Nilsson wrote:

> Vladimir Prus 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.
>>
> 
> [snip]
> 
>> 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?
> 
> As long as it also remains possible to build using the same steps as today,
> it's basically ok.
> 
> I've been missing a project-config (or equivalent) file for some time. This
> feature should not only apply to building boost itself, but also when
> building other projects that use bjam/boost.build as their build system
> (whether they are actually using boost libraries or not). 

Of course. I plan for this to be totally independent from C++ Boost.

> Some points: 
> 
> - This file should be easily editable by hand, for people who prefers to
> manually generate/maintain the project-specific configuration. This seems to
> be covered by your proposal above.

Yes, the file should be basically like user-config.jam, with extra statements to
specify build request and any options normally specified on the command line.

> - I think it should be possible to specify the name of the project
> configuration explicitly using command-line arguments, or preferably by
> using statements in a Jamfile. My main usage scenario for this is that I'd
> like to be able to maintain project-specific configuration files for
> different target platforms, storing the configurations in source control
> together with the code.
> 
> - It should be possible not to load the project configuration, even if it
> exists.

I've noted these points.

Thanks,
Volodya