KDE Workspace broken due to upstream CMake changes
Alexander Neundorf
neundorf at kde.org
Mon May 27 20:00:12 UTC 2013
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
More information about the Kde-buildsystem
mailing list