[CMake] Re: General modernization facility

[Rodolfo Lima]

Brandon Van Every escreveu:
> 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.

Well, maybe you're right in some sense. But let's look at cmake's code,
shall we? At Sources/cmFindBase.cxx:213 (cmake-cvs-20071219) we have the
following comment:

  // CMake versions below 2.3 did not search all these extra
  // locations.  Preserve compatibility unless a modern argument is
  // passed.

Then it tests the variable CMAKE_BACKWARDS_COMPATIBILITY, if it is 2.3
or below, a compatibility flag is set. Later (line 413), we have the
following comment:

  // Now that arguments have been parsed check the compatibility
  // setting.  If we need to be compatible with CMake 2.2 and earlier
  // do not add the CMake system paths.  It is safe to add the CMake
  // environment paths and system environment paths because that
  // existed in 2.2.  It is safe to add the CMake user variable paths
  // because the user or project has explicitly set them.

Isn't this an example of what you've meant? I mean, if I get an old code
(which doesn't have the CMAKE_BACKWARDS_COMPATIBILITY flag set) and use
it with a new CMake, I might get an unexpected behavior, different from
what the author intended.

Cmake already treats its compatibility issues like I've proposed. In
fact, I came up with this idea after seeing this code, just tried to
make a little more robust.

Maybe Brad King should comment on this issue since cvs annotate told me
he wrote this code.

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

People should be coding to the version of cmake available at coding
time. And, you know, if a cmake developer decides to change a behavior,
this should be documented. He would have to write a proper if clause
delimiting some version numbers. This action should be documented
stating that a certain feature or behaviour is valid from version X to
version Y, etc. This shouldn't be a problem.

> CMake has broken things before and will break things again.  It all
> depends on how ancient things get.

Not to break ancient code is a big plus. Even with autotools is nice to
be able to compile an old package.

Just trying to sum it up: some backwards compatibility framework is
better then none. I've seen features being let down because of lack of
it. We have come with two approaches, each one with pros and cons. Now
it's up to the cmake developers to decide if this issue deserves
consideration or not.

Regards,
rod