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