[CMake] CMake and Lua

[E. Wing]

> I am not seeing the merit of trying to support multiple scripting
> languages. This fragments CMake into many sub-language communities.
> Who would handle all the inevitable bugs? It's many times the work of
> maintaining a quality implementation with 1 scripting language.

I don't think this is necessarily as bad as you think. For a real
world example, look at Cocoa and Objective-C in the Mac world. Apple's
OS X is a direct descendant of NeXTSTEP which used Cocoa/Objective-C
to implement its GUI frameworks. Mac classic however did not. To hold
over old Mac classic people until they could rewrite, Apple introduced
a second completely independent framework called Carbon, but they told
people they should use Cocoa to get first-class looking applications.

As you describe, in this case, maintaining two separate frameworks was
a pain in the butt and each had different bugs and differences in
behavior. So I agree, this is a bad situation.

Cocoa is by far the superior framework, but many developers unfamiliar
with NeXTSTEP or new to OS X refused to touch Cocoa because they
didn't want to learn Objective-C. Objective-C is a very minimal
superset of C; basically C with objects and a very dynamic runtime. It
only takes a day to learn if you already know C or C++. Yet, there has
been huge resistance to learning Objective-C.

But Objective-C, being a really dynamic language has lots of cool
features and tricks. It supports reflection, introspection, and has a
robust runtime, so language bindings turned out to be very possible
and not terribly difficult to implement.

So over the years, different language bridges have been developed. The
two biggest and most complete are PyObjC and RubyCocoa. PyObjC has
been around for 10-20 years and was used heavily in the NeXTSTEP days
on Wall Street. Anyway, Apple has finally decided to include PyObjC
and RubyCocoa officially in the latest version of OS X.

This is great because now people who don't want to be bothered to
learn Objective-C may now use other languages to access Cocoa. And
Carbon is now declared deprecated so this framework can go away.

So a few of things to note:
- The language bridge is made possible to due good reflection,
introspection, and dynamism. Only languages that have similar
capabilities can bridge to Obj-C well. This means some languages like
C++ will never bind to Objective-C well. (Objective-C++ has a
different approach and purpose.)

- To make the bridge easy to implement and maintain, the bridge
languages don't change a lot of things around. Method names maintain a
1-to-1 correspondence and design patterns don't change. (An earlier
hand-made Java-ObjC bridge by Apple violated this and was a dismal
failure.)

- Because of the 1-to-1 correspondence, Cocoa framework questions can
generally be answered by anybody, regardless of language.

- There are some nasty areas in writing an Obj-C bridge, mainly
dealing with the pure-C aspects of the language since there is no
introspection/reflection/runtime support to figure these things out.

- The language bridges don't necessarily have to be known about and
supported by Apple. 3rd party communities implemented all the language
bindings. Apple realizing this, introduced "BridgeSupport" in the
lastest OS X, which provides more meta information about the
frameworks so language bindings are even easier to write, especially
for the nasty areas.


With respect to CMake, I believe if done 'right', (I know, big 'if'),
then building a language bridge shouldn't be hard, shouldn't fracture
the community, and won't require Kitware to know about/support or even
care what languages out there are being used to write scripts.

It's not obvious to me how to implement this the 'right' way though.
With the native CMake-script language, there are certainly impedance
mismatches with 'real' languages. However, if a Lua implementation can
be completed, I think all this will fall into place. Also, since Lua
has really great introspection/runtime capabilities, it might be
possible to bridge across Lua. There are already projects out there
that let you bridge/embed Lua with Ruby, Perl, and Python. And maybe
someday  Parrot will be finished.


-Eric