> 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake