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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
