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
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.
-- In a world without walls and fences, who needs windows and gates?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk