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

[Alexander Neundorf]

On Thursday 20 January 2011, Alexander Neundorf wrote:
> 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)

Typo !!!

Corrected version:

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

Just a note: this patch has zero effects and zero risk of breakage with cmake 
versions which don't have CMP0017, i.e. all cmake < 2.8.4.

Alex