Re: [Boost-build] Improving Boost Build?

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-05-16 02:14:13

John Maddock wrote:
> 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:
>

[snip]

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

I would like to add that not only the toolsets need to be documented - all
of the support modules such as 'set', 'path' etc etc etc would also need 
reference
documentation, and preferably also examples.

Also, the whole business of classes/objects, their usage and implementation 
needs to be explained and documented.

IMHO these points are among the first steps in getting more Boost.Build 
_developers_.

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

cxxflags / linkflags ?

> Likewise a consistent way of name
> custom-name-mangling the resulting libraries.

I assume you mean the toolset, toolset-version, boost-version, variant etc 
tagging?

In that case, this gets +1 from me. There is "common.format-name", but I 
don't
know just how generic that is.

Also, an easier way to add such name mangled (precompiled) libraries as 
dependencies to one's own targets would be greatly appreciated. I know this 
question has been raised before.

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

Interesting idea.

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

We could always hope for some developer in a largish company getting paid 
time
to improve the tool (and being allowed to give back to the community).

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

Yes, but with reference to earlier statements, I believe that better and 
more complete docs is the first step to take.

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

FWIW, I find this a good attempt in the right spirit and in the right 
direction.

/ Johan