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
> I wanted to discuss one Boost.Build change I want to make.
> 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]
> 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
> 3. ./bjam
> This step can be usually invoked with no parameters, reads the
> configuration information from project-config.jam, and builds
> 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