[CMake] CMake with Lua Experiment

E. Wing ewmailing at gmail.com
Tue Nov 27 09:50:00 EST 2007


Hi Ken,

Wow, thank you for playing with this. I personally think it's great.

Every so often, I have to write some evil stuff in CMake script, and
it always leaves me frustrated with things sometimes not working
correctly. Working with a well known and well defined language is a
big plus for me, and also makes it easier to convince others people to
pick up CMake. Remember the argument 'I don't want to learn another
language' also works against CMake because the majority of people are
not CMake users already. Having a simple language that is known,
proven, and documented is a real way to get past the barrier to entry.

Of all the scripting languages, I've found Lua to be both one of the
easiest to pick up by non-scripters, and also one of the easiest for
C/C++ programmers to quickly understand without triggering a visceral
response in them. The syntax is elegant yet powerful, and Lua syntax
more closely resembles C/C++ than many other popular scripting
languages which makes it friendly to C/C++ people. Since the majority
of people using CMake are C and C++ people, I think it is important to
consider the latter too because I was once burned by having to pick up
Tcl quickly in a predominantly C environment and I struggled with it.
Habits and conventions I took for granted in C like whitespace and
braces were something I automatically ignored, while it turned out to
be incredibly significant in a small piece of Tcl code I was trying to
get to work. (And the Tcl compile/runtime error I got was useless.)
For me, Lua has been very compatible with the C mental model, with
only a few annoyances (like != in C is ~= in Lua).

And from a marketing standpoint, it's easy to say, 'using the language
of World of Warcraft, Far Cry, Baldur's Gate, Grim Fandango, Escape
>From Monkey Island, and many others' and get people excited.


So some more specific notes:

The Windows line feeds and whatnot are mucking up my build attempt.


I don't think you need to use unpack. You should be able to just pass
a table. It is possible to write the implementation detail to handle
either case I believe.


It's true that CMake's language currently gives some nice features
like the ability to omit commas and quotes, and case-insensitivity.
There is a new macro processor for Lua that is supposed to help with
these kinds of things with the intent of helping projects create their
own domain specific customizations. It works on top of Lua so you
don't have to modify Lua itself. I've never used it myself and don't
know it's capabilities and limitations. The risk of this though is
that you now deviate from standard Lua documentation. However, if it
can be used in limited scenarios, there might be some benefits.

If quotes and commas are a real pain and you don't want to use the
macro thing, you can also pass things in as block strings and parse
them yourself, but I always worry about the reliability of these
things. Relying on the compiler for syntax errors is usually a plus,
but here's a snippet of what the syntax might look like:

-- Use square bracket quote for block string
sources = [[
    simpleLib.cxx
    simpleCLib.c
    simpleWe.cpp
]]

Then something has to be written to parse this string, presumably a
split on whitespace type thing (but what about filenames with spaces?
Bleh)



One suggestion, I personally like using a nested table to give
functions "namespaces". So instead of cm_add_library, you could do
cm.add_library. The standard Lua libraries do this (math., table.,
io.,). There are a whole bunch of documented tricks users can then
apply to simulate 'using namespace' and so forth.



On #include <lua.h>, because Lua can be placed anywhere (lua, lua50
lua51, lua5.1, etc), I recommend #include "lua.h" with a robust
FindLua.cmake module. (FYI, I on OS X, I have a framework.) I remember
somebody was working on one, and I was supposed to submit mine which I
have been lagging on, but it basically tries to deal with a lot of
this. One of the tricky parts though is how to deal with the Lua
standard library. Pre-5.1, it was traditionally a separate library
while post 5.1 it is often rolled together. But either way, people can
(de)bundle them. But if you embed Lua, this problem goes away. (Also,
every non-patch version of Lua reserves the right to break the API/ABI
so this is a secondary problem not bundling Lua has to deal with.)

Assuming Lua does become a permanent component, then embedding Lua is
easy enough and shouldn't impact the CMake build process much. Lua is
small and compiles fast (especially compared to the CMake core). The
Lua core is 100% ANSI C and purposely keeps a lot of platform specific
stuff out so it is really easy to build on any platform.

Thanks,
Eric


More information about the CMake mailing list