Re: Future development

David Abrahams wrote:
>>> 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

Now you're just being ridiculous.  Assembly language is just
a symbolic
representation of machine code, with an almost one-to-one
mapping, and
(sometimes) some macro capabilities thrown in the automate
the repetitive
and tedious parts.  Compilers don't have much use for macros
since they
are already automated tools themself.


>>> Cmake does the same thing.
>>
>> No, it doesn't.
>
> Are we going to have a "does not/does too"
argument?

Only if you're going to insist on trying to sell a poor
metaphor.


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

Don't be dense.  You know that I'm referring to makefiles as
scripts and
you know that's exactly what cmake generates.


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

1) The discussion of how cmake drives make IS technical.

2) You're not going to try to refute it because YOU CAN'T. 
Because my
assertion is obviously true on it's face.


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

I was referring to BB not needing an underlying make system,
as cmake
does, but I guess the point wasn't clear?


>> It does not produce "assembly language"
or anything even close to
>> it.
>
> That was an analogy.

And that was me pointing out how the analogy is wrong.


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

Why is it that every point that goes against you gets waved
off as having
"no technical content"?  Are you truly so myopic
as to not see how this
comment is totally relevant to the discussion?  From my
perspective, it's
the primary basis for the decision and apparently there are
others here
who agree with my assessment.


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

And that's why I'm glad it's not solely your decision to
make.  Whether or
not a tool is obsolete is very much a technical
consideration and if
you're going to ignore that kind of criteria when
determining the future
of any product you are very likely to make the wrong
decision.


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

Agreed, of course.


> We need higher-level abstractions than
> those provided by make in order to effectively manage
complex builds.

Yes.  And there's basically two ways to do that: (1) give
artificial life
support to the obsolete tool; or (2) develop a completely
new tool with
new paradigms to serve everyone into the future.  I'm opting
for the
latter.


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

If you're not interested in my opinion then why are you
perpetuating this
thread?  My original message (I thought) was pretty clearly
an offering of
one user's opinion.

You clearly have an agenda here to merge cmake with BB; I
clearly do not
want that to happen (and others seem to agree, so it's not
just me); and
you're clearly bent on discrediting my "opinion"
so you can continue to
promote your agenda.  Well, sorry my friend, but it's going
to take better
arguments than you have to offer to change or discredit my
"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.

That's a cute trick: call for "objective criteria"
and "empirical data" so
you can categorically discredit all opinions, no matter how
valid, that
oppose your agenda.  It seems your true interest is pretty
transparent.


> So far, the
> technical arguments in favor of using Cmake sound
pretty compelling to
> me.

And pretty much only you.


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

Oh, and there's a good bet.  How many folks here are looking
forward to
having to troubleshoot not only cmake but also the native
make tools AND
build tools on *every* platform that you build on?  Here's
another good
technical argument for you: KISS  (google it)


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

Boost can choose whatever it wants to use and I don't care. 
My concern is
for Boost.Build and the criteria presented here is solid.

~ray


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

On 10/05/07 18:15, Ray Lambert wrote:
 > David Abrahams wrote:
 >>>> 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

 > Now you're just being ridiculous.  Assembly language
is just a

Ray and Dave, I realize one or both of you are getting a
little
heated, but I think it would help tone things down if
phrases with "no
technical content" such as "being ridiculous"
were eliminated.

 > symbolic representation of machine code, with an
almost one-to-one
 > mapping, and (sometimes) some macro capabilities
thrown in the
 > automate the repetitive and tedious parts.  Compilers
don't have
 > much use for macros since they are already automated
tools themself.

I'm never programmed in assembly language or machine
language, but
this seems to make sense to me.

[snip]

 >>> 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.
 >
 > Don't be dense.  You know that I'm referring to
makefiles as scripts and
 > you know that's exactly what cmake generates.

OK, I thought that's what you were thinking, Ray; however,
"Don't be
dense" seems a bit strong.  (Of course this maybe
common where you
work and seems normal to you.  If so, I apologize for being
overly
sensitive [especially since the remark wasn't aimed at
me.]). OTOH, I
can see Dave's point because if you didn't mean shell
scripts, why use
the term "script" instead of the more accurate
term, "Makefile"?  I've
gotten the impression from past posts that Dave's very keen
about
using the correct term, and this is maybe why he
misinterpreted what
you meant by "script".

[snip]

 >>> It produces scripts 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.

 > Why is it that every point that goes against you gets
waved off as
 > having "no technical content"?

Did you mean to say *most* points or did you really mean
*every*
point?  I'm not being dense.  When I say "always"
or "every
time" in the middle of a heated argument, I usually
don't mean it.

I think Dave meant that "obsolete tool" has no
technical content
because it's a conclusion which *may* be based on some
technical content
provided earlier.  Also, "should be allowed to die in
peace" has no
technical content.  No one can base a decision on using
CMake based on
these remarks.  That's my interpretation of what Dave
means.

[snip]

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

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

> David Abrahams wrote:
>>>> 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
>
> Now you're just being ridiculous.  Assembly language is
just a symbolic
> representation of machine code, with an almost
one-to-one mapping, and
> (sometimes) some macro capabilities thrown in the
automate the repetitive
> and tedious parts.  Compilers don't have much use for
macros since they
> are already automated tools themself.

make is just a symbolic representation of the dependency
replationships between files and the build actions required
to satisfy
those dependencies, with an almost one-to-one mapping, and
(sometimes)
a whole pile of more advanced features thrown in to automate
the
repetetive and tedious parts.  Cmake doesn't have much use
for those
features since it is already an automated tool.

>>>> Cmake does the same thing.
>>>
>>> No, it doesn't.
>>
>> Are we going to have a "does not/does
too" argument?
>
> Only if you're going to insist on trying to sell a poor
metaphor.

Using words like "ridiculous" and "poor"
without justification don't
make your argument any more compelling.
>
>>> 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.
>
> Don't be dense.  You know that I'm referring to
makefiles as scripts 

No, I don't know that.  

> and you know that's exactly what cmake generates.

I don't claim to be an expert on Cmake; maybe you know
something about
it that I don't.  The fundamental declarative language
that's common
across Makefiles (and used by cmake) has little in common
with most
scripting languages, which are imperative, so it seemed
unlikely to me
that you just meant the Makefiles when you said 'scripts.' 
Also, you
put 'scripts' in quotes, which tends to indicate you're a
term from
Cmake's documentation.

>> 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.
>
> 1) The discussion of how cmake drives make IS
technical.

You didn't discuss how it drives make.  I'll admit that you
assert the
fact that it drives make, but there's absolutely no
contention about
that.  The rest of what you're saying is pure judgement.

> 2) You're not going to try to refute it because YOU
CAN'T.  

Of course I can't, as long as you get to define all the
important
terms: what constitutes obsolescence and what is pretty or
pig-like.

I don't accept your definition of obsolescence, and I claim
beauty and
porcinity are subjective and moreover irrelevant as far as
Boost's
decision about what tools to use is concerned.

> Because my assertion is obviously true on it's face.

Hehehe.  Obviously to you.  Not to me.

>>>>> 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.
>
> I was referring to BB not needing an underlying make
system, as
> cmake does, but I guess the point wasn't clear?

I guess not.  What *was* your point?  

Anyway, BB *does* need an underlying make system: the one
provided by
bjam (and Perforce Jam before that), and I can tell you that
the parts
of most make implementations depended on by Cmake are far
better
tested, optimized, and supported than the parts of bjam used
by BB.
Furthermore, most of your arguments against make apply
equally well to
pure bjam when used without Boost.Build.  The only
substantive
difference is whether the system is one-pass or two-pass.

>>> It does not produce "assembly
language" or anything even close to
>>> it.
>>
>> That was an analogy.
>
> And that was me pointing out how the analogy is wrong.

That was you stating that it is wrong, without explanation. 
That's
not very interesting.  If you want to actually tell me *how*
it is
wrong, I'd be very interested to hear it.

>>> 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.
>
> Why is it that every point that goes against you gets
waved off as having
> "no technical content"?  

I don't think you're scoring any points against me here. 
The validity
of the entire statement above rests on your ability to
define
obsolescence without reference to the usual dictionary
definitions
(what they have in common is "no longer in use"). 
That's why I say it
has no technical content.

> Are you truly so myopic 

I think we can do without all the name calling
("ridiculous," "dense,"
"myopic").  We can disagree without being
uncivil.

> as to not see how this comment is totally relevant to
the
> discussion?  From my perspective, it's the primary
basis for the
> decision and apparently there are others here who agree
with my
> assessment.

I'm not sure they do.  Nobody else has actually been
claiming that
make is obsolete.  Rene apparently objects to the
relationship between
Cmake and the underlying tools purely on testability
grounds, and
though I'm not convinced, I'm also not discounting his
objection.  I
haven't heard any other objections to using an
implementation of the
valuable Boost.Build abstractions on top of Cmake.

>> 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.
>
> And that's why I'm glad it's not solely your decision
to make.
> Whether or not a tool is obsolete is very much a
technical
> consideration 

Yes, but if the decision about what is obsolete is entirely
up to your
subjective and unmeasurable judgements ("has not kept
up with software
development; it's stuck in the 1970's") and ignores
objective data
like Benjamin Kosnik's list derived from
http://
popcon.debian.org/main/devel/by_recent (don't forget to
credit
make everytime you see make, autotools, automake, Cmake,
etc.) then it
doesn't in fact have any technical value.

> and if you're going to ignore that kind of criteria
when determining
> the future of any product you are very likely to make
the wrong
> decision.

Even if you think make is ultimately doomed (isn't
everything,
including C++, doomed?), it's hard to imagine that it would
become
unsupported, unstable, or unavailable in the next 20 years. 
Those are
the only effects of obsolescence that matter in this
context.  I'd be
surprised if you could even demonstrate that the use of make
is in
decline.

>>> 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.
>
> Agreed, of course.
>
>
>> We need higher-level abstractions than those
provided by make in
>> order to effectively manage complex builds.
>
> Yes.  And there's basically two ways to do that: (1)
give artificial
> life support to the obsolete tool; or (2) develop a
completely new
> tool with new paradigms to serve everyone into the
future.  I'm
> opting for the latter.

What makes you think Doug's implementation of Boost.Build's
major
functionality (on top of Cmake) does not have new paradigms
to serve
everyone into the future?  What makes you think Boost.Build
does not
"give artificial life support" to bjam and thus
Perforce Jam?  What
makes you think Jam is not obsolete?

>>> 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.
>
> If you're not interested in my opinion then why are you
perpetuating
> this thread?  My original message (I thought) was
pretty clearly an
> offering of one user's opinion.

I guess I was hoping that underneath that opinion there
would be some
useful, concrete data or insight that would help me to
understand the
pros/cons of adopting a Cmake-based system for boost.

> You clearly have an agenda here to merge cmake with BB;


No, I don't have any such agenda.  We already have,
essentially, a
reimplementation of major BB concepts atop Cmake.  I am
trying to
decide whether to support the replacement of BB with that
system for
Boost's building and testing needs.  My only agenda at this
point is
to try to convince myself of whether it's a good idea to do
that.  I
have to admit I'm starting to lean toward it, but I haven't
decided.

> I clearly do not want that to happen 

Either you have nothing to worry about, or it's too late,
depending on
whether you think Doug's system constitutes a merging of
Cmake and BB.

> (and others seem to agree, so it's not just me); and
you're clearly
> bent on discrediting my "opinion" so you can
continue to promote
> your agenda.  

Wow.  I hope you will accept my word when I tell you that
it's not
true.

> Well, sorry my friend, but it's going to take better
arguments than
> you have to offer to change or discredit my
"opinion".

I don't need to change or discredit it.  I can just decide
it's
invalid; however, I was hoping there would be something
worth
considering underlying it.

>> 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.
>
> That's a cute trick: call for "objective
criteria" and "empirical
> data" so you can categorically discredit all
opinions, no matter how
> valid, that oppose your agenda.  It seems your true
interest is
> pretty transparent.

Apparently not.

>> So far, the technical arguments in favor of using
Cmake sound
>> pretty compelling to me.
>
> And pretty much only you.

If that's actually the case, my interest in figuring this
out won't
amount to a hill of beans.

>> 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,
>
> Oh, and there's a good bet.  How many folks here are
looking forward to
> having to troubleshoot not only cmake but also the
native make tools AND
> build tools on *every* platform that you build on? 
Here's another good
> technical argument for you: KISS  (google it)

You appear to have really missed my point.  My point was
that the
parts of make used by Cmake are unsophisticated and by now
"just
work," and furthermore they work quickly.  They are the
parts most
beaten on by make's huge user community.  Unlike bjam, we
will not
have to troubleshoot the native make tools, and there are
lots of
people outside Boost who care if those tools break in
important ways.

>> Fair enough, but I think Boost as a whole has to
make its choice of
>> tools based on other criteria.
>
> Boost can choose whatever it wants to use and I don't
care.  

It's clear then why we've been talking past one another.

> My concern is for Boost.Build

I understand.  Well, I doubt if anything said here would
convince
Volodya to discard the bjam codebase and adopt something
like Doug's
8000-line replacement, and as far as I'm concerned anyone
who wants to
stick with that system can do so.  However, if Boost adopts
a
Cmake-based system, BB as we know it will lose its biggest
customer
and its direct relevance to Boost.

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

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