[CMake] Re: CMake script vs. Lua

[Brandon Van Every]

On Dec 14, 2007 2:29 PM, Rodolfo Schulz de Lima <rodolfo at rodsoft.org> wrote:
>
> I didn't quite get what you mean here about 'self-selecting nature of
> CMake community' (sorry, English language barrier).

It means, people who like CMake the way it is, tend to stick around.
People who have a serious objection to CMake the way it is, tend to
leave.  So I don't think we should ask CMake regulars whether
fullblown languages are beneficial to build systems.  I think we
should ask users of competing build systems, especially those that
have fullblown languages, i.e. SCons.  If nothing else, it would help
CMake stay abreast of competitors' capabilities.

> > Ken showed proof of concept for Lua.  "It's too hard" would be a
> > completely silly argument at this point.
>
> And for what I saw, its implementation could be better (no unpack, etc...).

Yeah.  In fact I saw his response of "well, we probably won't /
shouldn't do this, even though I've proven that we can do this" as
completely silly.  I compared it to arguing with myself about whether
I could adopt a dog.  "Oh I live in a tiny apartment."  It was a
perceived barrier only.

> > We do, however, have new scope and function operators in CVS CMake.
> > So we should all play with those for awhile before revisiting the Lua
> > issue, I think.
>
> That's the point. I even don't know if there's an agreement on the fact
> that cmake script is a good script or not. It seems it isn't because
> something basic as scoped variables got implemented recently, etc.

Lack of scoping is a seriously painful issue.  Everyone agreed on
that; that's why something was done about it.  Other things haven't
been so compelling.  Arguably, that's why nothing has been done about
them.  CMake script is not that bad, seen from that standpoint.  I've
written tons of CMake script.  I've been using CMake script where I
arguably should have been using Ruby.  I feel I have a pretty good
handle on its usability.

> Is it
> feasible to wait for the need of other obvious features (like return
> values from functions,

I've been getting along without them.  Where must you have them?  I
admit they'd make some things more convenient.  Autoconf / GMake has
${function arg} stuff, so I'm forever having to convert that to
SET(...)
statements on previous lines.  If CMake had functions that returned
values, then the migrations would be much more 1:1.  I haven't tried
the newfangled CMake function stuff in CVS.  It's not applicable to my
current project; I have to ship with a production-ready CMake.

> pcre,

Yes it is feasible to wait on this one.  A guy's working on it right
now and will probably have something for us soon.  I will also have
time to contribute to it once my current contract is over, if he
hasn't finished it by then.  Having done tons of CMake regular
expressions recently, I think a better regular expression engine and
interface is strategically important to CMake.

Lua doesn't come with PCRE-quality regexes anyways.  It's got its own
"funny" regexes, which have some better capabilities than CMake, but
it's also missing the "alternation" operator |.  Lua bindings to PCRE
are readily available, but I don't know their quality.  The point is,
there will be PCRE integration work even with Lua.

> etc..)?

I don't believe in the use of the word "etc." when having this kind of
debate.  State the exact things you need.

> I mean, as time progresses, it
> becomes more and more difficult to change root paradigms (like the
> script language).

That argument doesn't strike me as true.  We added scope and
functions, after all.  Truer statement: some things are easy enough to
change, other things are hard to change.  The trick is identifying
what's important to change.  Scoping / functions was both important
and "easy enough."

> So if cmake script is incomplete, why not change it to
> something more complete?

Because it could just be churn, and it increases maintenance burdens.
We need compelling reasons for Lua, not just "this would be a little
nicer."  Personally, I think the most compelling reasons for Lua are
(1) its marketing value, (2) it's well documented.  But I don't think
that's quite enough to make the switch.  What I'd really like to see,
is an example of a build system that's much better in a "fullblown"
language like Lua, that would be extremely painful to write in a
stripped down language like CMake.  We'll have to ask other build
communities about such a project; obviously it won't exist in CMake
code.


Cheers,
Brandon Van Every