Re: [Boost-build] Future development

From: Ray Lambert (codemonkey_at_[hidden])
Date: 2007-10-07 17:12:48

David Abrahams wrote:
 >> on Fri Oct 05 2007, "Ray Lambert" <codemonkey-AT-interthingy.net> wrote:
 >>
 >> Boost can choose whatever it wants to use and I don't care.
 >> My concern is for Boost.Build
 >
 > It's clear then why we've been talking past one another.

Indeed.  I'm afraid that I didn't understand that you were advocating 
for Boost's build tool only.  As a user of Boost.Build, I see BB as 
something independent from Boost (aside from an administrative 
relationship).

This begs a question though: is this how most Boost-folk see BB?  i.e. 
As just a supporting tool for Boost?  If so, that's very disappointing, 
as I see much more potential for it than that.

I'm not going to rehash any of the earlier arguments, many of which Rene 
has now done a better job of expressing than I did, but I do want to say 
something regarding my theory of make obsolescence, just to be sure the 
idea didn't get lost in the noise.  When I originally mentioned this in 
my first message of this thread, I realized it was likely to be 
controversial in general but I thought the idea might find a receptive 
audience here.  While I agree with Rene's description of it being 
"archaic", after some recent reflection (prior to this thread) I decided 
that I'm willing to go further and actually call it obsolete.

I mean this in the sense of it being unfit for the job (because the rest 
of the world has moved forward and it hasn't).  To evaluate my claim, 
one needs to examine it on its own, outside the presence of any 
"meta-make" or other supporting tools.  Imagine someone sitting down to 
write a new c++ project (of at least moderate complexity) using only 
make as the build tool.  That person has a daunting task ahead of them 
to set-up make to do everything that he needs.  In fact, he probably 
won't be able to achieve all his needs and will be forced to compromise 
to get something working.  This is clearly not an adequate solution.  
Make is simply not able to adequately satisfy the needs of a modern 
software project and, based on this, I call it obsolete.

Obsolescence doesn't mean that no one uses it anymore, nor that there's 
no support for it, nor that it fails to continue to execute its original 
functionality.  But it has been made obsolete by the demands of modern 
software development.  It clearly needs "crutches" to remain in use, in 
most cases, and the sheer number of such tools that are in existence 
testifies to this fact.

Meta-make tools try to provide such "crutches" for make in the form of 
enhanced functionailty designed to meet modern needs.  However, in 
general, I consider solutions of this nature to be "band-aids" to be 
used temporarily until a "proper" solution comes along.  Often in the 
software world, however, we keep archaic tools and concepts around well 
past their natural life spans out of some fear of breaking backwards 
compatibilty or something similar.  That's all well enough but I think 
there comes a time when a total change is necessary.  My recent thoughts 
have convinced me that we've reached that time w.r.t. make-related tools 
and I have some hope that BB is a candidate for the future.

Hence, I consider BB to be a "forward-looking" tool.  Conversely, I 
consider meta-makes to be "backwards-looking" tools.  That doesn't mean 
that these aren't good tools but they perpetuate the "obsolete" make 
ecosystem which I believe needs to be replaced.  And this is the basis 
for my claim that a merged BB and cmake system would be a step 
backwards.  As I see it, BB has already stepped forward by breaking the 
dependency on make.  Restoring that dependency through a merge with 
cmake, therefore, is a step backwards.

As for jam/bjam obsolescence, I don't believe this to be the case.  
Clearly there are issues with the jam-related pieces, as have been 
described here by others, but it sounds to me that they're related more 
to maintainability and usability rather than an inability to do the 
job.  Hence, I tend to agree with Volodya's proposed solution to replace 
the jam-related parts with a re-write in a modern, popular, and 
well-supported language such as Python.  That seems to me like a 
sensible solution that preserves everything that I like about BB while 
fixing many of the issues that are jam-related.

So, I hope that explains better where I'm coming from.  As I've stated 
before, my comments are intended only as input to the BB maintainers 
from the perspective of a BB user and they concern themselves only with 
BB itself as a stand-alone build tool.  And no one has to agree 
competely with my "make obsolescence" argument, but I hope you can at 
least see how I arrive at that conclusion and are willing to acknowledge 
the basic problems it addresses.

As for the Boost build system selection, I don't know how urgent the 
situation is there.  If it is urgent however, I would recommend that 
Boost look to existing tools to solve the problem, even if that means 
moving away from BB.  Cmake may very well be a good solution in this 
case.  If the need isn't so urgent, I would recommend that Boost wait 
and see how the next BB milestone develops and what comes out of it.  
Most importantly, I would recommend *not* "cannibalizing" BB, in the way 
being discussed, for the sake of Boost.  I feel that more will be lost 
than gained by doing so.

~ray

-- 
In a world without walls and fences, who needs windows and gates?