On Thursday 20 January 2011, Rex Dieter wrote: > On 01/20/2011 02:20 PM, Alexander Neundorf wrote: > > On Thursday 20 January 2011, Rex Dieter wrote: > >>> This is the code which would have to go into FindKDE4Internal.cmake in > >>> case of breakage: > >> > >> Looks ok to me, just built kdebase-runtime-4.5.95 with cmake-2.8.4-rc1 > >> yesterday (is that a good enough test?). > > > > Hmm, not necessarily. > > Were there warnings about files being shadowed, mentioning CMP0017 issued > > by cmake ? > > Yes there were lots of warnings. :(
The warnings are good. They show a problem which existed before, but we were not aware of it. In CMake you can add new stuff to modules in a fully backward compatible way. This new feature, e.g. in Foo.cmake, may be used by other modules shipped with cmake. If some project, e.g. KDE, happens to ship a slightly modified version of Foo.cmake, which does not yet have that new feature, can "shadow" the cmake version of Foo.cmake via CMAKE_MODULE_PATH, so a module from cmake, which include()s Foo.cmake, gets the "old" version from KDE, and not the new version from CMake (which has the feature), and so stuff breaks. The warning about CMP0017 appears in such cases. The new behaviour in this regard is that a project can not anymore shadow files from CMake via CMAKE_MODULE_PATH for modules shipped with CMake. You can think of this like an RPATH built into the modules shipped with CMake, and CMAKE_MODULE_PATH being "only" LD_LIBRARY_PATH. Alex _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
