Hi Ken, this is a reply to your email on the Lua list: http://marc.info/?l=lua-l&m=120275861422593&w=2
It is nice to see that there is interest in Lua as alternative scripting language. Since I've discovered Lua I thought it would be a nice drop-in for the actual CMake macro language. Here I wanna post some ideas about the general architecture. In principle CMake implements two thing, - a scripting language, - and a make/build-file generator. As I understand it, these two things are currently mixed up in CMakeLib: all commands parse the arguments (scripting functionality) and then call the generator function with the found arguments, for instance this->Makefile->AddSubDirectory(.. This makes it hard to introduce a new scripting language, if it should not only be a wrapper of the current cmake commands. Isn't this your ansatz in your Lua experiment? http://www.cmake.org/Wiki/CMake:Experiments_With_Lua http://www.assembla.com/wiki/show/CMakeLua I would choose a different way: First I would split the current CMakeLib into two libs, one which implements the macro language, and the other which implements the generator stuff only, nothing knowing about any scripting/macro language. Then a binding of the macro language to the generator lib gives you a backward compatible CMake version. If only this is done, nothing is won. But with this layout, it would be much easer to use other scripting languages. With this architecture you don't have to definitely exclude all other scripting languages when choosing Lua as additional new language. Kitware could officially support Lua and KitwareScripting, the old macro language, and at the same time provide a well proven cross-plattform build-file generator library which could easily be used by other scripting languages (imported as an external module). On the long run this gives you a much greater user/developer base, and gives the build-file generator library the chance to become the standard in cross-platform builds systems. Some scenarios I could imagine: - if there is a binding done with http://www.swig.org/ CMake could be used by all popular scripting languages - maybe Trolltech finds it convenient to replace their proprietary build-file generators, and join forces with Kitware. Then it is possible that CMake is sometimes part of Nokia/Symbian projects' build process - someone binds CMake to autotools/m4 (don't know if this is possible) - a PHP binding to manage the build process with a browser, don't know why someone would do this ;) - with a bjam binding it finds its way into boost (What's the current status of boost's cmake branch?) - "CMake everywhere" in analogy to the slogan of TT - SCons uses CMake to generate build-files as alternative to their build files - with Kross the scripting language becomes transparent http://kross.dipe.org/ More scenarios or comments are welcome. Best regards, Peter Kümmel _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake