[CMake] CMake with Lua Experiment

[E. Wing]

> (Aside: what's with the cm_ prefix?)

The cm_ prefix was something Ken put in his demo. I assumed he was
trying to 'namespace' the thing. I personally like the idea and really
think it should have been applied to the regular CMake language. Often
when I have to read other people's code, I can't distinguish between
the 'official' API functions are and the userland functions when I do
not know the official API very well. I certainly had this problem with
CMake when I first started out, and I also have this problem with
CMake functions that I forget about or don't know about either due to
legacy redundancy/obsoletion or new things introduced.

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

So you're not listening. What I said is:

cm_add_library( "simpleLib", "STATIC", "simpleLib.cxx",
"simpleCLib.c", "simpleWe.cpp")

is identical to:

sources = {"simpleLib.cxx", "simpleCLib.c", "simpleWe.cpp"}
cm_add_library( "simpleLib", "STATIC", unpack(sources))

In both cases, the function cm_add_library receive 5 strings as arguments.


I'm also saying that is it easy to implement cm_add_library so you can
handle the above case (the vararg case) but you can also handle the
case where the user does:

cm_add_library( "simpleLib", "STATIC", sources)

In this case, cm_add_library receives 2 string arguments and 1 table
argument. The implementation of cm_add_library can be easily written
to handle both cases so the CMake scripter can write whatever seems
most natural to them. This makes the need for unpack() unnecessary.





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

I'm not understanding what you're getting at. But I think this is
probably much ado about nothing. Once you get your files into a table,
you can do all your expected foreach/list stuff. There won't be any
excessive quoting here. I don't see any reason while the CMake FOREACH
couldn't also be exposed through a Lua API either so you should be
able to use which ever fits best.


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


Well, not really. Embedding Ruby (or Python) is a lot harder than
embedding Lua. There are very few languages that focus specifically on
this niche. Most languages want to be the end-all and offer great
libraries to easily build certain types of things (Rails, Twisted).
Lua's focus is embedding which is why it is a great tool for this
specific kind of job with regards to CMake.

As far as Ruby syntax is concerned, I don't see how it is
significantly different than Lua. All the Ruby code I've seen also has
quotes around string literals and commas separating items in lists.

But I wouldn't worry much about the speed of Ruby. Most of the
performance bottlenecks will be within CMake itself doing the heavy
lifting and file I/O. It's just nice that with Lua, you don't have to
fend off detractors on the speed argument so much. But I don't see it
as a real problem.

As for marketing, I can't predict the future. Any language is subject
to these whims. We could all be writing in Lisp some day. However, Lua
has been around for awhile  (it's older than Java) and I don't expect
it to disappear. And adoption of Lua has been driven more by the fact
that it's a really good tool for solving specific sets of problems,
not so much marketing. (It's just interesting that World of Warcraft
has suddenly changed the marketing aspect because the game is so
huge.) I can say with some certainty that even if the marketing loses
its luster, it will still be an easier sale than marketing CMake's
proprietary language.



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

> cm_add_library( "simpleLib", STATIC, sources)

So, as I said, there are some tokenizer/macro preproecessor things
available that are intended to help people create more domain specific
languages that work on top of Lua. But I am not terribly familiar with
them. I do know one of them was written by LHF, one of the Lua
authors. Maybe this is it?
http://lua-users.org/lists/lua-l/2006-09/msg00282.html

One thing to be aware of though. Notice strings are quotes, but
variables are not (like C/C++). So an ambiguity problem may be
created. So if I were to do something like:

myLibraryName = "simpleLib"
listOfFilesFound = cm_file(GLOB, "*.c")  -- wrapper around CMake FILE,
but utilizes return parameter
cm_add_library(myLibraryName, STATIC, listOfFilesFound)

Notice that all the quotes are gone by the cm_add_library command
because everything was somehow placed into a variable.