[CMake] Lua in a nutshell

[Fernando Cacciola]

Hi Brandon,

> On Tue, Mar 4, 2008 at 7:52 AM, Fernando Cacciola
> <fernando.cacciola at gmail.com> wrote:
>>  >
>>  > Nutshell: is it strategically a good idea to implement Lua support for
>>  > CMake?
>>  >
>>  > - CMake script must be maintained indefinitely for a small percentage
>>  > of users no matter what the migration strategy
>
> BTW, this point is intended to mean that CMake script must always be
> supported, even under the most wildly optimistic migration strategy.
> One can debate how many CMake script users will have to be supported
> indefinitely in practice, but there will always be some.  We can add
> languages, but we can't really take them away, not without a fork of
> the CMake code and community.
>
Right, that's a good point. Backward compatibility is always a pain, but is 
unavoidable.

>>  OK, time to see what Lua is...
>
> Or maybe see what Python is.  Just because SCons uses Python 1.5 and
> Waf uses Python 2.3, doesn't mean CMake couldn't use it.
>  The Python
> license is fine, it's just slower and not as easy to embed as Lua.
> What if Python finally speeds up and Jython goes somewhere?  An
> article that appeared today:
> "Sun hires Python pros in dynamic languages push"
> http://www.news.com/8301-10784_3-9884267-7.html?tag=head
>
I know Python and Ruby. I **love** both and I would have been so happy if 
CMake were bult on top of any of them.

I like Ruby a bit better, but just because, so either one is fine with me.

>>  > - 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.
>
> If I had a reason to be confident that multiple languages could be
> used seamlessly with equal engineering quality, maybe it wouldn't be
> so insane.

I don't see any need to support multiple languages.
IMO, at most one should be adopted and sticked too.

> Last night I thought about what the OO version of CMake
> would look like, for marketing not technical reasons.  Why not
> target.add_dep(dep1 dep2 dep3 ...) ?  The swizzle of transforming
> command(object ...) to object.command(...) is straightforward.
>
But this is just syntax, not OO.
I mean, method(object) is just as OO  as object << method or object.method 
or whatever notation you choose.
Real OO is in the concepts, not syntax.

A way to see the OO in CMake is by focusing on properties since these are 
already object-oriented.

> Mainstream programmers probably would be more comfortable with
> object.keyword(...) to set some state.

I for one am not interested in making mainstream programmers more 
confortable but in improving the technical quality of CMake. Good 
programmers can appreciate any language provided is well tought out. Python 
and Ruby are not just popular, they are great (Java is even more popular and 
it sucks).

>  A lot of the CMake command set
> is well defined, field proven, and stable.  I don't think anyone would
> have a problem mentally translating back and forth, the commands of
> the CMake interface that are actually crystal clear.
>
Which is *the* great thing about CMake. It's high-level focus, but you can 
be high-level with any programming paradigm.

>  It's things like
> separate_arguments() that need to be put to death, with type safety
> and so forth.  I suppose that's a liability of language choice: not
> all languages are equally type safe.
>
At that, Python and Ruby excel.

>   Still, all of this suggests a
> Virtual Machine approach to CMake.  The open source universe certainly
> clamors for it, so if it could be done to a high level of engineering
> quality, maybe it is not so stupid.
>
It would be very complex VM since the actual machinery is the C++ system 
underneath.
(commands map directly to C++ objects). Not that this is a bad thing, but 
ity wouldn't be a conventional virtual machine.

This is an important distinction since most other build systems out there 
are entirely script based (or almost so). The CMake scripting language OTOH 
is really just a wrapper to the underlying C++ system. From that POV, 
adopting other languag(s) seems simpler since the real stuff keeps being 
implemented in the C++ core.

Best


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