[CMake] Re: General modernization facility

[Brandon Van Every]

On Dec 18, 2007 8:32 PM, Rodolfo Lima <rodolfo at rodsoft.org> wrote:
> Brandon Van Every escreveu:
>
> >> We would have to guarantee that version 2.4.7 executes correctly every
> >> script made up till now.
> >
> > I don't see how we could.
>
> Well, Kitware has always been concerned with backward compatibility, so
> every script out there would work with cmake-2.4.7. I'd also throw
> cmake-cvs in the mix, since they still fight hard to maintain backward
> compatibility.
>
> > The author may have been completely unaware of the potential of the
> > error condition, having never seen the circumstances in which the
> > error occurs.  We don't know that "I wrote this using 2.4.7" means "I
> > want it frozen for 2.4.7."  Let's even say, for sake of argument, that
> > you provided an interface for the author to state exactly that.
> > version_freeze(2.4.7).  It still may not be a good idea, because the
> > author may not have full knowledge of the consequences of his
> > decision.
>
> But if you correct the behaviour, the script wouldn't work as expected.
> Is this a good thing?

We don't want things to work as expected, we want things to work correctly.

> 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).

> >> I don't think we need to tie "disruptive" features to version numbers.
> >  I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE).  I'm
> > willing to wait a loooooong time for it to become a default CMake
> > behavior.  I think include(Modern) is a good idea in principle, for
> > people who want to use a well-defined collection of forward looking
> > behaviors.  The idea may need refinement in practice, but the general
> > idea is "opt in."  Not "tie my hands."
>
> If you turn something into default behavior, it'll break backward
> compatibility.

Eventually that's acceptable.

> And as time goes by, the amount of disruptive features
> tends to grow. In the future to write a script I would have to write lot
> of set_property(GLOBAL PROPERTIES CMAKE_REQUIRE...)...

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.

> 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.

> PS: feel free to correct any English mistakes I make. I won't learn if I
> keep writing wrongly.

Haven't noticed any.


Cheers,
Brandon Van Every