[CMake] Lua in a nutshell

[Fernando Cacciola]

Hi Brandon,

> On Mon, Mar 3, 2008 at 5:11 PM, Fernando Cacciola
> <fernando.cacciola at gmail.com> wrote:
>> Brandon wrote:
>>  >
>>  > I am starting to wonder if the whole Lua thing is indeed a red
>>  > herring, and what CMake really needs is the best possible website to
>>  > document, tutorialize, and market CMake.  In other words, what we've
>>  > got is fine; go sell it.
>>  >
>>  I have the feelling that I'd like to get into *this* discussion (not
>> that
>>  SCon's related one), but I'm a newcomer much too late to the party, so:
>>  what's "the whole Lua thing" in a nutshell?
>
> Nutshell: is it strategically a good idea to implement Lua support for
> CMake?
>
OK, time to see what Lua is...

>  In my opinion:
>
> Pros:
> - higher quality 3rd party documentation that the CMake community
> needn't maintain.
> - CMake gets a popularity boost from Lua, as it's a mainstream
> accepted language.
> - Lua's corner cases are more ironed out than CMake script.  3rd party
> continues to iron them out.
> - proof of concept has already been demonstrated and was relatively
> easy to implement
>
These are pros of adopting any other scripting language, not just Lua
(which I don't know just yet).
I would think CMake's businness should be build systems (low or high level), 
not programming languages, so there is an appeal in getting rid of this 
responsability.
OTOH, if  CMake does provide one of its own, it should be IMHO of a much 
higher quality because as it is now, it shadows the rest of CMake (which is 
so great and that's a pity).

> Cons:
> - although doable, it's extra work to support 2 languages
> - without a comprehensive migration strategy, it would split the CMake
> community
> - CMake script must be maintained indefinitely for a small percentage
> of users no matter what the migration strategy
>
I suppose automated translation has been considered right?

> - too much programmability may cause people to treat CMake as more of
> a library or build component, rather than a standard end user tool
>
People always find the way to shoot themselves in the foot. I say don't 
worry about that and trust the programmer.

> Undecided:
> - Do advanced programming constructs really matter?  OO?  A fool's
> game / fad / waste of time?  Or is it a killer feature that will make
> or break products in the future?
>
My problem with the CMake scripting language is not that is less advanced 
than others. I could live with that.
My problems with it are these:

1.It's not case sensitive.

2.Closing statements need and empty () [at least they don't need to 
duplicate the expressions any more].

3.There is just a string type which can actually be a list pseudo-type. At 
the very least it should have a real list type, a bool type and an integer 
type.

4.Because of 3 there are no boolean expressions, instead, a long fixed list 
of values evaluating to false.

5.There are no nullable types.

6.Becasue of 5 there is the need for the hacky string value *NOTFOUND

7.It has no functions (implemented in the script itself I meant) [macros are 
not the same]

8.There are cached and non-cached variables but their distinction is not 
sufficiently clear nor properly formalized.

9.SET (assignment) works differently for cache and non-cached variables.

10."internal" function do not return values, cluterring the interface with 
return parameters which are not even modified as in other languages (via 
out, var, etc).

11.It has no data-structure support (except for the ugly pseudo-list hack, 
and I'm not even talking about OO here)

12.It has no scope.

13.Some conditionals don't take expressions but variables, while others do 
take expressions based on operators (EXISTS, EQUAL,  etc)

14.There is no distinction between multiple arguments and a single argument 
being a list. This is a real problem for the many functions that accept a 
mix of both.

15.Because of 14 there are is the need for named parameters (which are great 
in themselves), but these are implemented poorly, as mere additional 
arguments/list items, so a typo in a parameter name breaks the naming and 
mismatches the argument list.

16.Least but not least: the language is extensible but not in the user side. 
That is, I cannot *plugin* (entirely at the user side) my own "internal" 
functions even though the underlying system is quite extensible.


>>  If it has something to do with the CMake scripting language, well, I for
>> one
>>  would love to drop it and use something else, like.... (don't get me
>> started
>>  on the wrong tail)
>
> The archives contain abundant ink on this subject.  Well, bytes, whatever.
>
I'm reading....

Best


-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba