Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-07 22:10:49

on Sun Oct 07 2007, Ray Lambert <codemonkey-AT-interthingy.net> wrote:

> 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).

Me too.

> 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.

Me too.

However, I have become frustrated with our inability to provide a
sufficiently smooth experience for Boost users and developers, with my
inability to improve things by influencing the direction of its
development, and with my inability to understand enough of the
codebase to improve the situation myself.  I have to ask "what should
Boost use?" with my Boost moderator's hat on and not my
Boost.Build-originator-and-invested-designer hat.  Developing Build
systems is outside Boost's core mission.

> 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).  

It all turns on what job you're asking it to do.  Cmake doesn't ask
very much of make.

> 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.

My analogy to high-level language compilers and assemblers stands.

> 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.  

He's not talking about replacing the jam part, FWIW.

> 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.  

Is that milestone special in some way, or is that just a general call
for patience?

> 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.

That sounds awfully dramatic.  Who is talking about "cannibalizing?"
Are other build tools about to eat Boost.Build?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com