Re: Future development

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

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

Re: Future development

Thread: Re: Future development