Re: [Boost-build] Future development

From: Ray Lambert (codemonkey_at_[hidden])
Date: 2007-10-05 19:15:06

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.

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