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

[Alexander Neundorf]

On Thursday 20 January 2011, Rex Dieter wrote:
> On 01/20/2011 02:05 PM, 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:
>
> 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 ?
kdelibs would be good.

Make sure all packages which are found with 2.8.3 are also found with 
2.8.4rc1. There should be a FindPackageLog.txt file be created in the build 
directory which lists the found and not found packages.

If not, try again with the patch.

Thanks
Alex