Quoting Ken Martin <[EMAIL PROTECTED]>:
I doubt seriously we will adopt a second language in CMake. There is no question of maintaining the current language. It has to and will be kept in CMake. It was very easy to add Lua to CMake which is nice (literally it was probably 15 hours of effort). Part of this experiment was to see if it was even programtically practical to add a second language. It turns out it is. Doing a complete nice integration would be pretty easy except for variables and syntax. That is where the two approaches significantly differ and as others have posted that is one place where CMake currently does not scale well. For those of us accustomed to functions and local variables the macro command is not quite right. We do need to address the variable/scope issue in CMake and I am sure we will. Starting from scratch I would use Lua for all the benefits a mature language provides, but adding it (or transitioning to it) I *suspect* is not worth it. (although part of me thinks in the long ten-year-out view it is worth it) Sometimes these issues take a while to gel.
Just to make it totally clear as I was the one who "tell you off": if the future of CMake is Lua, then I am totally in and for it. But in that case, please, please remove the current language.
Every time someone creates a new Linux distribution, database engine or programming language to unify them all, it's a new one I have to learn and support.
About regular expressions, I have started an implementation of regular expressions using PCRE 7.4 and the official PCRE C++ bindings (the ones contributed by Google last year).
-- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake