Re: [Boost-build] Future development

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-10-06 02:03:19

David Abrahams wrote:
> on Fri Oct 05 2007, "Ray Lambert" <codemonkey-AT-interthingy.net> wrote:
>> David Abrahams wrote:

>> as to not see how this comment is totally relevant to the
>> discussion?  From my perspective, it's the primary basis for the
>> decision and apparently there are others here who agree with my
>> assessment.
> 
> I'm not sure they do.  Nobody else has actually been claiming that
> make is obsolete.

I won't claim it's obsolete. But I would claim it's archaic. The way it
defines the dependency graph and node actualization is not designed to
take into account the complexity of building modern modular software.
What I understand Ray to be arguing is that it's a less than ideal
choice to base a make system on top of another one as archaic as make
when there are better choices even if the better choices are less populous.

> Rene apparently objects to the relationship between
> Cmake and the underlying tools purely on testability grounds, and
> though I'm not convinced, I'm also not discounting his objection.

You might want to put yourself in the mind of a new Boost user adn walk
through the process of what it would take them to start using Boost.
Essentially, mentally rewrite the getting stared guide and at every
point think of how you want to present the Boost C++ Libraries package
to users. In each of those think of what it would take the Boost
developers to provide that presentation. And at each point think of what
users would do if they run into problems, and hence how would Boost
developers respond. I know this is not something that Boost has
traditionally done or thought about, but it's got to be hashed out
before deciding to switch. As it's the only way you'll know if you are
truly taking a step forward.

> I
> haven't heard any other objections to using an implementation of the
> valuable Boost.Build abstractions on top of Cmake.

And I'm also raising the support objection, both before and immediately 
above. I've also mentioned some specific features that are requirements 
for Boost, but those could be considered within the testing umbrella.

>> You clearly have an agenda here to merge cmake with BB; 
> 
> No, I don't have any such agenda.  We already have, essentially, a
> reimplementation of major BB concepts atop Cmake.  I am trying to
> decide whether to support the replacement of BB with that system for
> Boost's building and testing needs.  My only agenda at this point is
> to try to convince myself of whether it's a good idea to do that.  I
> have to admit I'm starting to lean toward it, but I haven't decided.

OK, but why are you leaning toward it? The only reasons you've given so 
far are that Cmake is not developed/supported by Boost.Build people, and 
that it supports some "high" level set of features. The first I still 
think is a mirage as compared to the people supporting BB. And the 
second seems to be balanced by the set of basic features Cmake doesn't 
support. Did I miss something?

> My point was that the
> parts of make used by Cmake are unsophisticated and by now "just
> work," and furthermore they work quickly.  They are the parts most
> beaten on by make's huge user community.  Unlike bjam, we will not
> have to troubleshoot the native make tools, and there are lots of
> people outside Boost who care if those tools break in important ways.

I think that's a big assumption on your part. I'm fairly certain we will 
end up troubleshooting the native make tools Cmake is based on. And also 
troubleshooting Cmake itself. For the basic reason that we will push the 
functionality provided by them in the same way we push the functionality 
provided by BB+bjam, and analogous to how we push the functionality of 
C++ compilers. And for every error in the build system we will have to 
determine where the problem lies, just as we do today, except we will be 
doing it for an addition N set of make systems.

>> My concern is for Boost.Build
> 
> I understand.  Well, I doubt if anything said here would convince
> Volodya to discard the bjam codebase and adopt something like Doug's
> 8000-line replacement, and as far as I'm concerned anyone who wants to
> stick with that system can do so.

Even if you could convince Volodya, you could not convince me to abandon 
BB+bjam. I personally use it outside of Boost. And it's the reason I got 
involved in Boost.

> However, if Boost adopts a
> Cmake-based system, BB as we know it will lose its biggest customer
> and its direct relevance to Boost.

I suspect that's not the case. Boost may be the most public user of BB, 
but I get the impression that Sandia is a bigger BB customer. But 
perhaps we are using different definitions of "bigger". But as a 
comparison some "real" number seem appropriate:

* BB milestone 11 was downloaded about 37K times. Which would be an 
indication of possible outside users. (Note, I can't find download 
counts for Cmake, so perhaps Kitware can look those up and provide them.)

* Freshmeat stats for Boost.Build:
» Rating:  8.44/10.00 (Rank N/A)
» Vitality: 0.51% (Rank 304)
» Popularity: 0.73% (Rank 7781)
    Record hits: 7,955
    URL hits: 4,225
    Subscribers: 15

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo