Re: [Boost-build] Future development

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-05 03:21:45

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

>>> > After looking into gnu automake and it's complexity, it dawned on me
>>> > (actually, I had just never considered it before) that anything
>>> > based on the traditional make system is a waste of time because make
>>> > itself is antiquated and decrepit and no longer solves the problem
>>> > it was originally intended to solve very well.  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.  Cmake does the same
thing.

> My argument is that make isn't.

It is certainly up to the task of what Cmake uses it for.

> Assembly/machine language is *the* platform upon which *all* other 
> software development is done.  

Assembly and machine code are very different.  You can have many
different assemblers -- with different capabilities -- that target the
same machine.  There's only one input syntax for machine code.

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

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

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

> Oh sure, it does still work, but so does a horse & buggy.  (And a
> H&B uses no gas and doesn't pollute; but I bet you're not willing to
> trade your car for one anytime soon...)

Exactly.  Unlike a horse and buggy, all makes I know are *extremely*
fast at the jobs for which they are used by Cmake.  The speed of
dependency analysis and issuance of build instructions (all make is
used for by Cmake) is one of the first things that gets optimized, and
make users scream if it is ever slow.

I get the impression that you and Rene haven't taken the time to
understand how Cmake works.  In most (maybe all) cases, it's not
intended to generate a standalone native make system.  In general, the
makefiles it generates can't be used by themselves.  All the
interesting jobs (like tracing header dependencies) are done by Cmake.

>>> > cmake, IMO, would be a step backwards from this (I'm
>>> > trying to get away from other build systems and obsolete ones;
>>> > adding an extra layer to allow an obsolete system work correctly
>>> > just makes the whole thing more complex; a pig in a pretty dress is
>>> > still a pig.)
>>>     
>> Even as a replacement for bjam?
>
> If, as a replacement for bjam, it still generated native makefiles, then 
> YES.

Just because assembly language doesn't support classes doesn't mean I
don't want my C++ compiler targeting it.

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