Boost logo

Boost-Build :

From: John Maddock (john_at_[hidden])
Date: 2007-05-15 14:15:41


Irrespective of what happens with the CMake vs BBv2 debate, it's apparent
that there is still plenty of support for bbv2: indeed, I would echo
comments that it's a pleasure to use, provided you don't need to dig in and
write new rules yourself :-)

So, can we improve things to the point where 99% of the remaining issues are
dealt with? I think so, the things that come to mind are:

1) Consistent command line options (as Vladimir has already brought up): use
"feature=xyz" or "--feature=xyz" consistently throughout. The first of
these looks to be the more commonly used within BBv2 at present, so I'd vote
for that, and keep "-" and "--" options for controlling how bjam itself
behaves (as in the -d and -a options).

2) Better docs. Yes, I know it's been said before, but we really must get
the existing toolsets and their options documented. This need not take too
long if someone would step up and volunteer to do it.

3) Most of the current problems seem to stem from folks trying to build with
non-default options. Can we have a consistent way (across toolsets) to
inject compiler or linker specific flags into the command line: actually I
suspect we may have this already? If so it needs documenting and pointing
to from the getting started docs. Likewise a consistent way of name
custom-name-mangling the resulting libraries.

4) Relating to the above, I wonder if we could have a "generic" toolset that
used the environment variables CXX, CXXFLAGS, LDFLAGS in much the same way
that the autotools do. If necessary the top-level configure script could
make use of this to behave in a more autotools-like manner.

5) More BBv2 developers :-) I actually think we do tools rather well - both
quickbook and BBv2 are so very nearly where they need to be, but just need
that final push that only more developers (and a wider audience) can bring.
Part of the problem here is that Boost attracts folks interested in C++
libraries, and who don't necessarily want to spend their time hacking
Jamfiles or whatever. I'm not sure how solve this, unless maybe these tools
can acquire a life of their own outside of Boost as well as within it.

Anyway these are just a few random thoughts, hopefully presented in the
spirit of trying to find a positive way forward. I'll look forward to
seeing what people think,

Regards, John Maddock.


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk