[PATCH] Re: KDE 4.6.0: go or no go?

[Alexander Neundorf]

On Thursday 20 January 2011, Ian Monroe wrote:
> On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf <neundorf at kde.org> wrote:
> > On Thursday 20 January 2011, Dirk Mueller wrote:
> >> On Wednesday 19 January 2011, Dirk Mueller wrote:
> >> > so the general consensus seems to be against slipping the schedule and
> >> > inserting a RC3.
> >> >
> >> > This means that we need to solve bug 246678. Given that there seems to
> >> > be no fix in sight (no comment in the last 14 days), can we mitigate
> >> > it. is there a way to disable whatever causes the problem by default?
> >> > what would be the patch for that?
> >>
> >> Hi,
> >>
> >> I think the attached patch should make the services be disabled by
> >> default, thereby avoiding kde bug 246678. I'm asking for a review and a
> >> comment whether we can go ahead with this workaround for KDE 4.6.0.
> >>
> >> As the general consensus was (previously) already against slipping the
> >> schedule, I need a solution NOW to be able to release 4.6.0 in time.
> >
> > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ?
> >
> > If not, please do so.
> >
> > There has been a relatively significant change in it wrt to how include()
> > and find_package() find their files (now when a file which is part of
> > cmake calls include() or find_package() it first looks in
> > CMAKE_ROOT/share/cmake/Modules/ instead of first looking in
> > CMAKE_MODULE_PATH).
> >
> > I didn't have a lot of time since mid of December, so I didn't get around
> > to give it a try. Also today I won't have the time and then there's
> > already weekend, and I won't return before late Sunday.
> > If it breaks (should error out somewhere related to
> > FindPackageHandleStandardArgs), please let me know.
> > Setting cmake policy CMP0017 to NEW should fix this breakage if it
> > occurs. This would have to be done at the top of FindKDE4Internal.cmake
> > where the other policies are set too, inside a if(POLICY CMP0017) guard.
> >
> > IMO if this breakge occurs, this is something which we *must* fix before
> > the 4.6.0 release. I spent basically months of arguing and testing about
> > this issue with the cmake devs to get this new behaviour (without the new
> > behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way
> > round, depending on how you see it) into cmake.
>
> Delaying 4.6.0 at this point due to a cmake that barely any distros
> are using seems quite foolish to me (assuming it is an issue).

No, this is not foolish.
All distros will use cmake >= 2.8.4 in the future.
It would mean that KDE 4.6.0 will forever be unbuildable with any cmake >= 
2.8.4.

This is the code which would have to go into FindKDE4Internal.cmake in case of 
breakage:

if(POLICY CMP0017)
   cmake_policy(SET CMP0011 NEW)
endif(POLICY CMP0017)

And I think the breakage is there.
I was 2 weeks on vacation over the holidays, and just today I finally catched 
up with email. The respective patch was merged into cmake master early 
January.
For testing whether KDE 4.6 branch builds with cmake 2.8.4rc1 I don't have 
time tonight, and then we are already visiting people until late Sunday.

So please, as release coordinators, make sure this release builds with current 
cmake. If it doesn't, the patch above should fix it.

I was working hard on this more or less constantly since last September, to 
come to a solution of the problem in cmake which is suitable for KDE. It took 
me many many hours, sweat, ... to get this, so please don't ship a KDE which 
does not build.
And there's an easy way to fix it (see above).

Alex