Boost logo

Boost-Build :

From: Ray Lambert (codemonkey_at_[hidden])
Date: 2007-10-05 11:37:31


David Abrahams wrote:
> on Thu Oct 04 2007, Ray Lambert <codemonkey-AT-interthingy.net> wrote:
>>>> > ... Software development
>>>> > has moved forward but make has not; it's still stuck in the 1970's
>>>> > and Bell labs. It's high time for a new solution.
>>>>
>>> In the same way that assembly-language programming is antiquated and
>>> almost nobody does it anymore... except compilers.
>>>
>> Nice try, but that comparison misses the mark by a wide margin. Few
>> folks might write assembly language these days but assembly language
>> is still completely up to the task.
>
> The task of representing low-level instruction streams. Some
> assemblers have sprouted sophisticated macro systems and other
> high-level constructs (sort of like some makes have sprouted
> complicated features), but somehow compilers just seem to generate
> fairly straightforward, low-level asm code.

Compilers do that because there IS NOTHING ELSE at that level.

> Cmake does the same thing.

No, it doesn't. It generates 'scripts' to drive another, obsolete tool.
To refer to an old metaphor, it puts a pretty dress on a pig.

>> Assembly/machine language is *the* platform upon which *all* other
>> software development is done.
>
> Assembly and machine code are very different.

Not so much, really, but, whatever...

>> Meta-make systems try to treat make like
>> a platform, but it isn't; it's just a tool and a very crude one at that.
>
> That's all Cmake needs: something that can handle low-level targets,
> dependencies, and build instructions.

Which is more than a non-meta-make system, like BB, needs.

>>> CMake is just a compiler that produces makefile "assembly-language."
>>
>> Perhaps; if you look at it through thick rose-colored glasses. ;)
>
> What am I overlooking by viewing it that way? Seriously, I want to
> know.

The point of this comment was to further suggest that you have an
over-inflated view of what cmake actually does. It does not produce
"assembly language" or anything even close to it. It produces scripts to
drive an obsolete tool. Cmake provides artificial life support for make.
Make should be allowed to die in peace. It's time has come and gone.

>>>> > Any solution that builds on top of make is a waste of time because
>>>> > all it's doing is extending the life of something that's really
>>>> > already dead for all intents and purposes (it just doesn't know it
>>>> > yet).
>>>>
>>> By what measure is it already dead?
>>>
>> By my measure. As I argued in the remainder of my message, it has
>> not kept up with software development; it's stuck in the 1970's.
>
> So is assembly language. Just like make, it doesn't represent the
> high-level constructs we need in order to write expressive
> programs/build descriptions.

Wrong. Assembly language never was intended to provide such things and it
still works today just as well as it did decades ago. It also remains a
vital tool in software development.

Make, OTOH, was conceived as a way to help manage software builds but is
no longer up to that task (without help from additional tools, such as
cmake). If it can no longer serve its intended function then it is
obsolete and we need a new solution. Meta-makes have tried to prolong its
life but they're just crutches. A better solution calls for a completely
new and different tool.

Dave, I respect your opinions and your choice of tools, even if I don't
agree with them. But I also have my own opinions and choices based on
many, many years in this profession. You don't have to agree with them
but there they are nonetheless.

The point of my original post was to communicate to the BB maintainers
what the value of BB is from the perspective of it's users (or at least
some of them).

I don't want a meta-make system and I don't care how well it works.
That's partly why I chose BB.

If BB merges with cmake and becomes a meta-make tool, I will very likely
look for another tool. That's just the reality of the situation.

~ray


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