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

[Rex Dieter]

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?).

-- Rex