[CMake] CMake with Lua Experiment

[Brandon Van Every]

On Nov 28, 2007 3:13 AM, E. Wing <ewmailing at gmail.com> wrote:
> > (Aside: what's with the cm_ prefix?)
>
> 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.

Yeah but that's your fault.  :-)  Do enough CMake and you're gonna
know that add_library isn't something anyone made up.  I will admit
that a few of the uncommon functions could throw me.  Like site_name,
which I only learned the other day after 2 years of hardcore staring
at CMake all the time.  But I looked it up no big deal, right?
Furthermore, the CMake 2.6 docs have a better breakdown, there's a
"CMake Commands Only" section with a HTML index.  These are separate
from the standard modules, which now have their own section.  Module
names are exceedingly verbose, you're not going to mistake them.  So
it's trivial to learn the reserved commands, there's maybe ~60 of
them, all concisely indexed in one place.  The depreciated commands
have been moved out, thinning the ranks.

> >> 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:
>
> In both cases, the function cm_add_library receive 5 strings as arguments.

No, we're talking past each other.  I said I figured it out after
reading the docs for 15 minutes.  I was saying, in a long-winded
manner, that CMake script's ${list} is equivalent to Lua's
unpack(table), and that CMake is less verbose than Lua for list/table
dereferencing.  Since this is an operation that I do all the friggin'
time in 1/2 the lines of code I write, I consider it important.

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

And I think rewriting all the CMake functions to dereference
lists/tables on the user's behalf is busywork.  Nor do I, as a
programmer, want my lists/tables automagically dereferenced.  When
it's my turn to write standard modules, macros, or functions, I want
clear expectations about who's gonna do the work.  What the expected
type of input is, and what an error 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.

And a bit smaller.

> As far as Ruby syntax is concerned, I don't see how it is
> significantly different than Lua.

And a bit more PCRE.  Lua's inherent regexes are weird.

> All the Ruby code I've seen also has
> quotes around string literals and commas separating items in lists.

Ok my bad.  I keep thinking of Ruby as "souped up Perl."  Seems like
Perl, Make, CMake, and various shells are the sane ones as far as
string entry.

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

Ain't gonna happen.  The market has spoken: Lisp is weird.  People
will use it, and its use may even increase, but it's never going to be
a majority language.  Rather, the majority languages will steal Lisp
features and make them less weird.

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

But that's wrong.  Should be
add_library(myLibraryName, STATIC, ${listOfFilesFound})
where of course we've implemented ${} instead of unpack() ;-)

For any given CMake function, we know what argument types we expect.
The programmer is responsible for dereferencing, we're not going to do
it for them.  We just have to parse the keywords like STATIC, and pay
attention to fixed positions at the beginning of an argument list.  In
fact, come to think of it, "if it's a CMake reserved function, hand it
off to a special argument processor," would solve much of the problem.
 Then you're just down to changing Lua table constructors, so that
they don't require quotes.


Cheers,
Brandon Van Every