Re: CMake and Lua

["E. Wing" <ewmailing@...>]

I know I'm late to the party, but I don't have much time to devote to
these threads. But I wanted to chime in.

I disagree with the sentiments that a Lua binding for CMake would not
be useful (or not useful if not 'Lua-centric'). I think Ken
articulated some of the major points very well and I agree with all
the points on his list. And I'm very happy to hear he hasn't abandoned
the idea completely yet.

I've been using CMake for several years now. For trivial things, it's
tolerable. But the moment I need to do something complicated, I dread
every minute of it. I often feel like I'm fighting the language and
dealing with its idiosyncrasies or bugs instead of the actual build
system. There are a number of modules I've contributed to CMake, but I
know of limitations in them, but I am unmotivated to improve or fix
them because I find the language too unpleasant to want to deal with.

I can say that I'm not alone in my opinion of the CMake scripting
language. Anecdotally, I would estimate that over half the people I
have met that have evaluated or had to deal with CMake dislike if not
hate the CMake scripting language.

I've also done my share of evangelizing CMake. I do believe it is the
best build system generator around despite my personal feels about the
scripting syntax. But I've found that most people I introduce CMake
too can't get over the scripting syntax. Most developers
understandably want to work on their code, not the build system.
Aesthetically, CMake script is a syntactic shock for most developers
I've worked with (who work mainly with C-inspired languages). In
contrast, Lua doesn't set off all the alarm bells in these same
developers. (There was already some discussion on these points in an
earlier related thread which I won't repeat.)


As for binding Lua to CMake, I think Ken is already on the right track
with his original experiment.
(http://www.cmake.org/Wiki/CMake:Experiments_With_Lua) He has a fairly
elegant centralized place that binds all the CMake API functions to
Lua. I think this is great. The real remaining trick to be answered is
how to best deal with variables, particularly if interoperability with
existing CMake scripts is desired.

I'm not advocating 'Lua-centric' Lua-isms in a CMake/Lua scripting
binding, whatever that might mean. But I do believe there are some
Lua-isms that can be easily adopted to make things simpler, clearer,
and more concise. But the real point is by just allowing Lua to
interface to the CMake API, we now give the scripter the ability to
write in a simple, well-documented/designed/supported/tested language
and the scripter can decide to utilize the power of Lua as they see
fit, whether it be the use of data structures, well defined escaping,
or perhaps something that hasn't been imagined yet. (One random idea
example...if you needed some random, non-standard module like LPeg
support in your build system (complex project) you might be able to
include the source to LPeg with your project source, build LPeg first
in your  project, then use Lua's plugin system to dynamically load the
just built LPeg module, and then use the module to do whatever you
need to do in the rest of your build system, all done seamlessly.)

Thanks,
Eric