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

[Ian Monroe]

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

Seems like a reasonable goal for 4.6.1 though. Remember there's not
much time between these releases. 4.6.0 might end up on users
computers for a longtime (so its important to work out runtime
issues), but the window when distros are going to be building 4.6.0 is
relatively small.

Ian