Re: [Boost-build] Future development

From: Ray Lambert (codemonkey_at_[hidden])
Date: 2007-10-04 22:45:21

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?