On Dec 14, 2007 2:38 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > It really boils down to this: There is no way we can ever stop > supporting the current cmake language. It would be a huge break in > backwards compatibility.
Gee I'm getting paid to migrate a huge build system, from ancient crufty GNU Autoconf / GMake crap to CMake. Writing a translator to go from CMake script to Lua script, both under Kitware's control, would be cake by comparison. I'm not saying it would be a trivial project, but it's certainly a doable one, if other compelling reasons to move to Lua present themselves. "There is no way" really means "we have not contemplated, nor have we been willing to contemplate, the ways." >From the client's perspective: they're willing to suffer the huge disruption of moving to a new build system, if the old build system has gotten so painful to utilize, that it's making them completely miserable, impeding their productivity, and preventing their growth in new markets. In this respect it's pretty obvious why GNU Autoconf / GMake are bad: they don't support MS Visual Studio at all. Now, is lack of "fullblown" language capabilities going to make CMake seem similarly bad at some point? I don't know the answer, but it's certainly the strategic question. > The prospect of having two languages forever > is not something I would like to do either. So, we will continue to > improve the CMake language as needed. It's an answer. My question is, is there something that no matter how much you tweak CMake script, it really can't do? > (Of course, I am now regretting answering the email in the first place > as I said I would....) Do you expect pity? *Many* people have come to this list, asking after "fullblown" language capabilities of some sort or another. If nothing else, there is clearly an ongoing educational need on this topic. We know what state the wiki / online docs / shipping docs / dead tree docs are in; they're not going to fulfill the educational need. You could write a FAQ along the lines of "why we shouldn't have to talk to you, or answer questions about, CMake script in a comparative language context." Or you could see it as an opportunity to convert people, and to take their issues seriously. I will remind: far more people don't use CMake, than do. Having to learn Yet Another Scripting Language is one of the perceived barriers. So addressing the issue, or *appearing* to address the issue, is strategically important. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
