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