Re: [boost] Boost.Build changes for 1.38

Subject: Re: [boost] Boost.Build changes for 1.38
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2008-11-03 03:17:33

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). 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.

- 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.

/ Johan