[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Tuesday 12 October 2010, Alan W. Irwin wrote:
...
> cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)
>
> because you absolutely need CMP0017.  I believe most projects
> (including PLplot) will eventually need that policy as well because
> there is a tendency to copy and modify CMake find modules to the
> project's special needs for any mature project.  Thus, I assume PLplot
> will need CMP0017 in the future, but when that occurs I will bump our
> minimum version to a high enough value so we are assured of having
> that policy.
>
> Am I missing something?

Yes.
The (currently known) problem is that FPHSA.cmake in cmake had features added 
in a backward compatible way, but projects which have a copy of an older 
(e.g. cmake 2.8.2) FPHSA.cmake break, because their older version is not 
forward-compatible to the one in cmake 2.8.3, and because of the handling of 
CMAKE_MODULE_PATH their "old", not-forward compatible version is confronted 
with the parameters for the new version, which they cannot handle.

The new CMP0017 would *by default change* the behaviour, in order to avoid 
that breakage.

What could break: projects, which
* have a copy of some cmake module shipped with cmake in their 
CMAKE_MODULE_PATH
* AND which rely on the fact that when include()ing/find_package()ing some 
other module shipped with cmake (where they don't have a copy of), that this 
called module (from CMAKE_ROOT) gets their own copy of the previously 
mentioned module loaded when it does a include()/find_package()

I think such constellations should be quite rare.
Such projects would break.
They could be fixed again by either setting CMP0017 to OLD, or by having the 
full chain of cmake modules as a copy. E.g. if they rely on FindPNG.cmake 
getting their own copy of FindZLIB.cmake, they would have to include also 
FindPNG.cmake in their sources.

Alex