Hopefully other people will spend time debating the merits / demerits of this, as people have gotten sick of hearing me talk about CMake and Lua as of late. I'm happy that my irritance has caused people to continue to discuss the possibilities, however. I will make one point:
On Sat, Feb 23, 2008 at 6:20 AM, Peter Kümmel <[EMAIL PROTECTED]> wrote: > > 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. I am not seeing the merit of trying to support multiple scripting languages. This fragments CMake into many sub-language communities. Who would handle all the inevitable bugs? It's many times the work of maintaining a quality implementation with 1 scripting language. It wouldn't get handled, so CMake's reputation would suffer "because the Python implementation isn't so good" or whatever. How do I advise someone who's using a different language? I can't just show them working code, I can't just tell them to file a bug report with a trivial reproducer. I have to understand their language, or tell them how to "abstractly" solve the problem, or just punt. Not all scripting languages have nice licenses. For instance, Ruby has a somewhat onerous Artistic License, compared to CMake's BSD license. Most of the languages other than Lua are somewhat bloated, both in terms of execution size and speed. In short, I do not see value in trying to be all things to all people. That's an expensive way to do business. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake