> The other is that a non-trivial portion of CMake is written in the scripting > language ala the Modules directory. So supporting multiple languages becomes > problematic. Most languages are not designed to mix with other languages. I > doubt you can mix python and Lua and expect them to be able to access each > other's variables out of the box. But with the Modules directory we either > have to have a copy of each module for every possible scripting language, on > the fly converters between any two scripting languages, or something like > that to make it work. Trying to figure out how to manage the mixed > CMakeScript/Lua variables by itself is already a bit of an issue to > providing a Lua binding much less adding other languages on top of that. > Hopefully that makes some sense :)
While I agree that the variable problem between CMake-script and any other language is non-trivial, I think it becomes less of an issue once you do make it to a well known dynamic language like Lua. There already seem to be a handful of projects that bridge Lua to other scripting languages and deal with many things including variable bridging. Lunatic Python - two-way bridge between Python and Lua (best documentation) http://labix.org/lunatic-python Lux (embed Lua in Tcl, Python, Perl, Ruby) http://www.equi4.com/wikis/lua/25 Rua (use Lua under Ruby) http://rua.rubyforge.org/ Ruby-Lua http://raa.ruby-lang.org/project/ruby-lua/ Inline::Lua - Perl extension for embedding Lua scripts into Perl code http://search.cpan.org/~vparseval/Inline-Lua/lib/Inline/Lua.pm Calling Perl from Lua http://thomaslauer.com/comp/Calling_Perl_from_Lua Maybe some day there will be Parrot http://www.parrotcode.org/ http://www.parrotcode.org/talks/LuaOnParrot.pdf -Eric _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake