Brandon Van Every escreveu:
We don't want things to work as expected, we want things to work correctly.
This is getting nowhere...
Can you create an example of such error condition?
What if VERBATIM behavior becomes easier to work with? Or quoting
behavior in corner cases? What if macros no longer consume double the
number of escapes? What if ^ and $ start matching line endings
instead of the beginning and end of the file? We don't know how much
the author knew about the code he was writing. It would be better to
handle variations of behavior according to the specific feature,
rather than by version number, so that the author can tell us what he
wanted. set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS
TRUE).
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. Cmake may
afterwards change this behavior, and when running scripts for a certain
version range, do the old way. From the top version onwards, do the new way.
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.
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),... I think it's
better to stick to version number designators.
It'd be better to
specify the version of cmake I'm working on and that's it.
No it isn't. It doesn't identify the specific behaviors that have changed.
Sorry, I cannot express myself clearer than I did in English, if someone
here speaks Portuguese, please step in :)
Brandon, I think it does. By 'identify the specific behaviors that have
changed' you mean have a documentation of what has changed? It's up to
Kitware to decide if something new breaks compatibility or not. If it
does, a simple if clause would make cmake work the old way with old
scripts and the new way with new scripts. I can't explain this any better...
Regards,
rod
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
