Re: Future development

David Abrahams wrote:

> on Thu Oct 04 2007, Ray Lambert
<codemonkey-AT-interthingy.net> wrote:
>>  When I was looking for a build system for my new
project earlier
>> > this year, I rejected cmake and decided to go
with BB for very
>> > specific reasons.
>>     
> All due respect to your intuition about cmake, but this
would carry
> much more weight for me coming from someone who had
actually used it.
>   
Fair enough.  Having worked with other meta-make systems,
however, (such 
as imake and mkmake) I don't think my conclusions about it
are that much 
of a stretch.

It could do the most amazing, stupendous, unbelievable job
in the whole 
world at what it does and I would still reject it because,
as I tried to 
explain, I consider the very concept of a meta-make system
to be fatally 
flawed and it's not something that I want to deal with (any
more).


>> > 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.  My argument is that make
isn't.

Assembly/machine language is *the* platform upon which *all*
other 
software development is done.  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.


> CMake is just a compiler that produces makefile
"assembly-language."
>   
Perhaps; if you look at it through thick rose-colored
glasses.  ;)


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


>> > I believe in the idea that was put forward by
Alan Kay: "Simple
>> > things should be simple and complex things
should be possible."
>> >
>> > Alas, SCons failed this test (for me, at
least).  Very simple things
>> > were indeed simple to implement.  However,
even something moderately
>> > hard quickly rose to the level of being
difficult to the point of
>> > being almost impossible (and certainly beyond
the limits of my
>> > patience, which, for me, amounts to about the
same thing).
>>     
> I find Boost.Build to be the same way... and I was
initimately
> involved in its design and development.
>   
Well, different strokes then.  I haven't hit the wall with
BB yet.


>> > So I tried BB again.  This time I got it to
work and I've never
>> > looked back since.
>>     
> Have you ever had to do something moderately hard in
BB?
>   
Nothing hugely difficult but I've managed to painlessly do
everything I 
needed to and I've gotten much farther with it than I did
with SCons.

And I'm not trying to trash SCons here.  I'm sure it has
lots of good 
stuff in it and I'm sure the developers have done some great
work on 
it.  It just didn't work for me.


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

~ray

-- 
In a world without walls and fences, who needs windows and
gates?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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-cons
ulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build