[CMake] Re: General modernization facility
Rodolfo Schulz de Lima
rodolfo at rodsoft.org
Wed Dec 19 13:44:23 EST 2007
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
More information about the CMake
mailing list