Ken Martin wrote:
In VTK and ITK we did design a language independent toolkit and wrapped it
into Tcl, Python, Java etc so we have done that and have a good feel for it.
But for CMake I do not think it is a good idea for a couple reasons. One is
fragmentation of the community/support.
Every time this fear of fragmentation/forks.
Should we really care about it? I don't know.
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 :)
Yes, the existing modules are a problem. It makes no sense to support
multiple languages there.
Then it is only possible to provide a C++ interface so that all the
module stuff works "behind the scene" (behind the interface), using one
scripting language only. And if a new module should go upstream it
must use this language.
But all official-shipped modules could be made accessible through the
C++ interface, so that one still could call the generator functions
from a other language.
Anyway, I'm not sure any more if my initial idea was really that good.
Peter
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
