[CMake] Lua in a nutshell

[Fernando Cacciola]

Hi Ken,

>> 2.Closing statements need and empty () [at least they don't need to
>> duplicate the expressions any more].
>
> Technically I believe this is possible. It has been asked for in the past.
> Just a change to the yacc IIRC. I tend to not mind () personally.
>
It has to be more or less as easy as that.

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

>> 12.It has no scope.
>
> Well directories have scope
>
Which is way too astreay for my taste.
One wonders: is there a file-level unit of scope? what are the rules? what 
if I use "include" instead of "add_subdirectory". Can I load a module with 
that same local scope?

IMO the "add_subdirectory" command is itself half-cooked, I would have 
preferred a better thought out modules design.

>  and always have, now functions do as well. There
> is no midstream push/pop scope ala "{" "}" but you can just make a 
> function.

Ya, that's not big deal.

> There is also some object scope supported through the use of properties on
> targets/source files/directories/tests/etc.

Which means that is some concept of "objects" in Cmake, but they are a bit 
like those of old VB in the sense that the only objects are those hard coded 
in the system.

>> 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.
>
> You can define your own commands and even override the default commands 
> from
> the script level.
>
Ya, but you need a special script command to invoke it,
I mean the hability to define actual commands because the underlying C++ 
framework is quite flexible.

> You can also use the C plugin API to dynamically compile and load a run 
> time
> plugin.

This one I didn't knew about.

>  We discourage this as it is more prone to errors (user running a
> 32bit CMake but building a 64 bit executable tries to dynamically load a 
> 64
> bit module into a running 32 bit cmake, etc, etc)
>
That should just blow up in the users face.. so he wil just go ahead and 
correct it.
Again, trust the programmer :)

> This could be fixed by
> running the plugin in a separate process etc but I'm just not sure we 
> really
> want to expose/encourage that low level of an API.
>
I don't think you need to do that, just let it break.

Best


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