Re: Improving Boost Build?

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build