[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