On Sat, Mar 1, 2008 at 7:08 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > Especially in open source, I think it is > reasonable to make developers do trivial amounts of work to move on, > at some point, if the migration tools have been thoroughly tested and > proven in the field.
I did just realize one "gotcha" however that I hadn't previously considered. *Which* version of CMake would be translated? Writing a translator for 1 or even a few recent versions of CMake is one thing. Trying to be bug-for-bug compatible over the entire history of CMake's development is quite another. There would have to be some cutoff point, where if you want compatibility with a really ancient version of CMake, you have to just use an old version of CMake, and not expect new features or ongoing development. Then again, if translation was proven for CMake 2.4.x forwards, for a goodly number of years, and officially supported, then it could pave the way for translation efforts even farther back into CMake's history. Say, for instance, 80% of the builds out there are translatable because they're sufficiently modern. 20% aren't, and it takes a much longer time to make them translatable. So, it may still be possible, but 2 years wouldn't be long enough to force migrations. More like 5..10 years. On that timescale, it's not that different from supporting 2 languages indefinitely. Even if the support can indeed be terminated in 10 years, it's a lot of time to be splitting the community with 2 languages. It really all depends on how far back the CMake compatibility has to go. A far more likely scenario is, CMake --> Lua translators are used to get 99% of the CMake community onto Lua. The remaining 1% contract with Kitware for their special needs. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
