Re: [Boost-build] Future development

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

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.bixoft.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-consulting.com