On Nov 27, 2007 11:35 AM, Ken Martin <[EMAIL PROTECTED]> wrote: > 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.
Sounds like me arguing with myself about whether I could adopt a dog. "Oh I live in a tiny apartment." Well that didn't turn out to be important. I think the syntax for any CMake embedded language has to handle variable length input. Lists of stuff are so common in a build system that the language should handle them gracefully. I don't know enough about Lua to know whether this is natural in it. It's definitely not natural in C++ and I wouldn't choose C++ for specifying a build system. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake