KDE 4.6.0 and cmake-2.8.4-rc1

Alexander Neundorf neundorf at kde.org
Thu Jan 20 21:58:57 CET 2011


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


More information about the release-team mailing list