On Dec 19, 2007 1:44 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > The solution I proposed solve these problems. If I write a script where > my cmake matches ^ to line endings, I'd expect this behavior, and my > script would work correctly as I, the developer, expected.
What if you were translating from a legacy build system, you expected regexes to work pretty much like they do in every other language or system, it turns out they don't, and you didn't test for the corner cases because the legacy build system had a truly vast number of option permutations to trundle through? You might not hit the bug for a year. Whereas if the behavior had been "fixed" in later versions of CMake, you'd never have a problem. The big flaw in your agenda is you assume the developer knows what's going on, and totally understands the behavioral implications of any given CMake version number. In the real world it ain't so. That's why we need specific "opt in" options. If the developer said set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS TRUE) then we know exactly what the developer intended and what to provide. Do you expect me to track all the behavioral differences by version number as CMake evolves? You noticed the number of people asking "which version of CMake did behavior X first appear in?" People have no clue. > >> If you turn something into default behavior, it'll break backward > >> compatibility. > > > > Eventually that's acceptable. > > Maybe not... a solution the maintains complete backward compatibility > should do it always to cope with legacy scripts. At least I think that's > cool. CMake has broken things before and will break things again. It all depends on how ancient things get. > > That's what include(Modern) is for. You can look inside of > > include(Modern) to see what it specifies. That's what better > > documentation is for. > > So maybe one day we will have include(Modern), then include(Moderner), > then include(Modernerst), then include(ÜberModern),... Its contents would have to be managed according to some policy or mission statement. This is no different than deciding what's a bug, what's a feature, what to put in a new version of CMake, what to leave out. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake