[CMake] Re: General modernization facility

[Brandon Van Every]

On Dec 19, 2007 1:44 PM, Rodolfo Schulz de Lima <rodolfo at rodsoft.org> 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