Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-05 12:55:42

on Fri Oct 05 2007, "Ray Lambert" <codemonkey-AT-interthingy.net> wrote:

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

Totally false: http://www.bixoft.nl/english/course6.htm

>> Cmake does the same thing.
>
> No, it doesn't.  

Are we going to have a "does not/does too" argument?

> It generates 'scripts' 

It does?  Can you point me to anything that supports your claim?  As
far as I understand it generates very basic Makefiles.  

The rest of this has no technical content:

> to drive another, obsolete tool. 
> To refer to an old metaphor, it puts a pretty dress on a pig.

so I'm not going to bother to try to refute it.

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

Again, http://www.bixoft.nl/english/course6.htm and others like it
tell a different story.

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

No, that's exactly what a non-meta-make system needs.  BB gets that
functionality directly from bjam.

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

In other words, no technical content.

> It does not produce "assembly language" or anything even close to
> it.

That was an analogy.

> It produces scripts 

References please?

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

Again, no technical content.  I'm looking for technical reasons that
Cmake can't work for us.  Your judgement that it uses a tool that is
"obsolete" and "should be allowed to die," shouldn't make any
difference in Boost's choice to use Cmake or not.

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

Again, http://www.bixoft.nl/english/course6.htm and others like it
tell a different story.

> and it still works today just as well as it did decades ago.  It
> also remains a vital tool in software development.

There is no measure by which you claim that make isn't a vital tool in
software development.  However cumbersome, the vast majority of
open-source projects rely on it in one way or another.

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

Did make deteriorate, or did the demands of build management increase?
Obviously it's the latter.  We need higher-level abstractions than
those provided by make in order to effectively manage complex builds.
Just like we need functions, classes, modules, and types to manage
complex programming jobs.  Assembly language is "no longer up to that
task" in the same way.  In what way -- not purely based on your
judgements about the badness of make -- is my analogy flawed?

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

Yeah, but I'm not interested in my opinion (I don't have much of one
in this area yet) or -- I'm sorry -- in your opinion.  I'm interested
in finding some fairly objective criteria and or empirical data by
which we can make a decision about the use of Cmake.  So far, the
technical arguments in favor of using Cmake sound pretty compelling to
me.  The only plausible technical arguments that I've heard against it
so far are Rene's about maintenance and testing, and I'd like to check
those against people's real experiences.  If Cmake works as I
understand it to, it relies only on the features of the underlying
make system that just have to work, and work well, or make wouldn't be
able to build anything -- so it's hard to see where the testing
nightmare comes from.

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

Fair enough, but I think Boost as a whole has to make its choice of tools
based on other criteria.

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