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.b
ixoft.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.b
ixoft.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.b
ixoft.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-cons
ulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
