Re: [Boost-build] Improving Boost Build?

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-17 02:56:13

on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:

>> > 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.
>>
>> Yeah, that's important.  But when even the people originally supposed
>> to be co-developers on BBv2 have been worn out trying to understand
>> the project's code, how are we going to get 3 or 4 more people to
>> devote enough time to actually succeed where others have failed, and
>> then make big contributions?
>
> First answer I have to this question, is documentation. Let's please
> either settle differences the manly way and call a spade a spade: we
> have poor documentation, and thus let's fix it.

When you say "let's," who are you talking about?  I'm not going to fix
it.  I don't understand the system well enough to do so.  Who does?

> Yes, the pioneers have been burned out trying to make Boost.Build the
> build system that it is today -- and I guess not getting enough
> positive feedback contributes to the frustration. 

No, the frustration for me comes from having a codebase I could not
understand from the first day I returned my attention to the project
after kicking it off...  and things have not improved in that respect,
from my point-of-view.

> So the third answer to this question is that rather than relying on
> the pioneers to do all the work, I'd much rather be mentored by the
> pioneers (if time and materials allow it) in terms of answering "how
> to do this?" questions than actually burdening the original
> developers with the task of actually making the changes. 

I think only one pioneer can really help you.  I only know the core
bjam language and a few details around the edges of the higher-level
BBv2 system.  For everything else, I have to dig deeply into the code
myself and often I don't find the answers I seek.  

>> That's the bottom line, IMO.  Who is going to step up and devote
>> enough time to make something that can work as well as CMake?  In
>> CMake it's one line to build a graphical binary installer.  We
>> simply don't have enough time and resources to reach that level of
>> sophistication.  Further, the CMake model has some advantages in
>> that it is not trying to do configuration work every time you
>> build.  Yes, we could do that in BBv2, too, but personally I just
>> don't see the point in trying to outrun a project that actually has
>> a bunch of knowledgeable developers and company funding behind it.
>
> I guess shooting for the stars is not a bad idea, but I guess the
> point of the discussion is now diverging on the actual use of CMake
> in the Boost C++ Library and the improvement of Boost.Build. Trying
> to make Boost.Build what CMake is might not be for the best interest
> of Boost.Build users -- rather we should put in features that
> Boost.Build users (such as myself, and others on the list) would
> like to have in Boost.Build, and get more people involved in the
> effort.

How would you like to have a system that begins building
instantaneously when you ask it to build?

> So as far as the question of using CMake or not using CMake in the
> Boost C++ Library is concerned, I'd leave that up to the Boost
> developer community at large. However for the current discussion of
> improving Boost.Build, I don't particularly see the need to turn
> Boost.Build into a CMake look/work-alike if we intend to keep
> Boost.Build a distinct and usable (better?) build system that it is.

Here's my point: *especially* if Boost isn't going to be using BBv2 as
its main build system, I simply can't afford to spend any more energy
trying to improve it.  I don't think BBv2 is better than CMake by any
truly objective criterion (although I may have an aesthetic preference
for some BBv2 design choices), and I think CMake has some real
advantages over BBv2.  My research even indicates that it's easy to
add usage-requirements to CMake.  Even though BBv2 is -- to a
significant degree -- my vision, I'm not afraid to admit that someone
else has done a better job.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com