[CMake] CMake with Lua Experiment

[Brandon Van Every]

On Nov 28, 2007 1:48 AM, George Neill <georgen at neillnet.com> wrote:
> On 11/28/07, Brandon Van Every <bvanevery at gmail.com> wrote:
> > - better scoping
> > - higher quality, outsourced documentation
> > - outsource core language bugs
> > - popularity boost for 5 years
> > - some advanced programming constructs gained
>
> I certainly can't debate those (unless CMake developers make significant
> changes to the core LUA libraries).
>
> Is backward compatibility with the current language a goal of the LUA
> experiment?  I ask because the examples spoken of on this list appear to be
> trying to mimic the current CMake syntax.

I think mimicry is a goal to some degree, so that CMake script
veterans are comfortable with migrating, and so that knowledge of how
to use CMake is not indelibly split into 2 camps.  For instance, "a
list in CMake script is a table in Lua" is an important paradigm to
maintain.  I think there should be no difference whatsoever in CMake
command, constant, and variable names.  If I want to cut 'n' paste
CMake script code to Lua code, or vice versa, I should be able to get
away with the minimum of fiddling.  In fact, the conventions should be
so similar that a CMake script --> Lua converter should be trivial to
write.  Some CMake veterans have kicked and screamed about having to
learn something new.  My thought is, there really shouldn't be
anything to learn.  I mean, after reading the Lua docs for 15 minutes,
it's almost obvious how CMake Lua *could* be done, *if* a couple of
warts are removed.

I don't think there's any meaningful way to talk about "backwards
compatibility" from Lua to CMake script.  I did raise some issues
about Lua now vs. Lua 5 years from now.  We see that SCons is on
Python 1.5.2.  That will happen to CMake with regards to Lua.

What I'm now interested in, is the degree to which Lua can be
customized as a Domain Specific Language, so that CMake can control
its own fate.  Specifically, I'd like to see excessive quoting go
bye-bye.  I'd also like a shorter way to dereference a table than
unpack(table).  ${table} would work for me, although I don't know how
well it would be received in the Lua community.


Cheers,
Brandon Van Every