[CMake] CMake with Lua Experiment

[Brandon Van Every]

On Nov 27, 2007 10:13 PM, E. Wing <ewmailing at gmail.com> wrote:
> I think you are misinterpreting some things about the Lua syntax.

 My understanding of Lua syntax improved greatly after reading the
docs for 15 minutes.

> Or we could exploit the varargs capability and not even use a table
> and just list things one by one:
> cm_add_library( "simpleLib", "STATIC", "simpleLib.cxx",
> "simpleCLib.c", "simpleWe.cpp")

The programmer desired to use a variable.  In CMake script we would write
add_library(simpleLib STATIC ${sources})

> This is actually what unpack(sources) was doing. Unpack was basically
> flattening/unpacking the table and passing each element in the table
> as a separate parameter.

(Aside: what's with the cm_ prefix?)  In Lua we could write:
add_library("simpleLib", "STATIC", unpack(sources))
I consider the quoting and the unpack() to be more verbose.  The
commas don't bug me, I think because I don't have to hit SHIFT to type
them.

> Lua's varargs ability automatically kicks in
> and unrolls the thing. As I said,  the use of unpack() was
> unnecessary.

I'm doubting that's correct.  I doubt that sources and unpack(sources)
are the same thing at all.  Pretty unreasonable for a language to
treat a variable representing a table, and the expansion of the table,
as exactly the same thing.  In CMake script, a LIST and a ${LIST} are
not the same thing.

> > That paradigm is crippled with respect to FOREACH and LIST style processing.
>
> I'm not completely sure what you are after here, but Lua also has a
> for/foreach construct for tables so you can use that too.

Yes I know.  I was saying that passing "file1.c file2.c file3.c" is
not a solution to Lua's excessive quoting problem, because you'd be
sacrificing desireable processing capabilities.  We want to be able to
operate on lists/tables of stuff with FOREACH, LIST, individuated
parameters, and so forth.

> > 3.6. Why is SCons written for Python version 1.5.2?
>
> That's an interesting and legitimate point. With Lua, though, the
> issues are a little different. If CMake adopts Lua, then it should be
> embedded with CMake (especially since it is not standard with Windows
> and Mac). Because you embed Lua, the CMake authors have complete say
> on which version is used and is not influenced by what the most
> popular Linux distro has installed and is available to the masses. So
> CMake has final discretion over which version is used.

The point is that the marketing luster of Lua will fade.  The legacy
CMake builds will all be using an old, hoary version of Lua.  CMake
will have to support those old builds to some degree.  It won't be
able to utilize newfangled Lua stuff, if the newfangled stuff breaks
backwards compatibility.  I bet there are problems between Python
1.5.2 and 2.5.1, although I'm not up on them.  I bet the Python
community doesn't consider Python 1.5.2 a sales point, if they stare
closely at SCons.  Now, people may not stare closely.  And in any
event, the luster of Lua will probably last 5 years.  But then it'll
be over, and the real question will be, was it a cool choice for text
processing?  'Cuz that's what a build system mostly is.

What we really want is Ruby without the licensing hassles.  And a bit faster.

> An additional thought is to export global constants (variables), so we
> can basically create keywords. So instead of:
> cm_add_library( "simpleLib", "STATIC", sources)
> we could drop the quotes around STATIC:
> cm_add_library( "simpleLib", STATIC, sources)

That's an improvement.

I wish we could get rid of quotes in places that don't need them.  How
easy would it be to modify Lua in that regard?  So, CMake would be a
Lua variant rather than straight Lua.  But it would still be 95% the
same, and Lua quotes would work as documented... you just wouldn't
always need them.  Most of the marketing value of Lua would be
retained.  And that marketing value isn't permanent anyways.  Only
drawback I see, is I suppose quoteless Lua strings might bugger third
party Lua libraries, unless some nice marshaling to external libraries
is possible.

If Lua has some kind of preprocessor, it would be trivial to regex the
input file for certain string types, then add the quotes to keep Lua
happy.  If it can't be done then throw an error about lack of quotes.
The docs would have a teeny tiny addendum to describe the Lua dialect.
 Such mods shouldn't be culturally verboten to Lua people anyways.
It's supposed to be an embeddable and customizable language.

> (We also might consider namespacing the keywords: CM.STATIC.)

No.  It's a build system and Lua is the embedded language to serve the
build system.  That's the context for anything anyone is ever gonna
do.  The cm_ prefixes should go bye-bye.  Constants in CMake script
should be exactly the same as constants in Lua script.  It should be
trivial for a CMake script veteran to pick up CMake Lua, and wherever
possible, it shouldn't give the CMake script veteran a rash.  It
should be an obvious and desireable migration path; otherwise, what's
the point?

> I would say to most
> outsiders, seeing Lua 5 used instead of Lua 6 is still a much less
> significant deal than users having to worry about learning CMake
> script and also dealing with their own version changes (1.8 vs 2.0 vs
> 2.2 vs 2.4 etc).

I've been around since 2.2.  CMake *script* hasn't changed much since
then, just the available functions.

Ok, my current opinion is straight Lua ain't quite good enough.  Can
we turn it into 95% Lua that's 100% CMake?


Cheers,
Brandon Van Every