KDE Workspace broken due to upstream CMake changes

[Alexander Neundorf]

On Monday 27 May 2013, Ben Cooksley wrote:
> On Tue, May 28, 2013 at 7:37 AM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Monday 27 May 2013, Rolf Eike Beer wrote:
> >> Am 27.05.2013 09:13, schrieb Ben Cooksley:
> >> > Hi all,
> >> > 
> >> > It seems that a recent upstream change in CMake has now broken the
> >> > build of KDE Workspace. Can someone please fix or prod CMake upstream
> >> > into revising their policies?
> >> > 
> >> > The lack of warning here concerning the change is a little irritating.
> >> > 
> >> > -- Looking for XkbLockModifiers in X11
> >> > 
> >> > CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE):
> >> >   Target "cmTryCompileExec744440252" links to item
> >> > 
> >> > "/usr/lib64/libXpm.so "
> >> > 
> >> >   which has leading or trailing whitespace.  This is now an error
> >> > 
> >> > according
> >> > 
> >> >   to policy CMP0004.
> >> > 
> >> > CMake Error: Internal CMake error, TryCompile generation of cmake
> >> > failed
> >> > -- Looking for XkbLockModifiers in X11 - not found
> >> 
> >> That's what the policies are for at all ;)
> > 
> > hmm, not really.
> > CMP0004 is not new. It was working with cmake 2.8.10, so it should, well
> > must, work also with 2.8.11.
> 
> Does this mean we have found a regression in CMake?
> Or is the policy being enforced more strictly now?
> 
> (ie. should CMake be fixed, or do we need to be fixed)

I think the rule is quite simple: a new cmake release must not break existing 
builds.

Alex