FindQt4 and Mac support

[Alexander Neundorf]

On Wednesday 02 December 2009, Andreas Pakulat wrote:
> On 02.12.09 11:13:41, Mike Arthur wrote:
> > I'm just wondering how someone would go about replacing some of our
> > modules with those provided in upstream versions of CMake. FindQt4.cmake
> > for example pretty radically different from the latest CMake versions and
> > fails in lots of ways on OSX 10.6. I don't think we have enough manpower
> > to watch the CMake changes and backport everyone individually and it
> > seems like a massive duplication of effort to me.
>
> Alex tried to port lots of changes from 2.6.x FindQt4.cmake (and I think

Should be "...is still busy porting..."
IOW I'm not done yet, and the support for OSX is actually one of the things 
were I'm feel most unsure.
It would be great if you can help me there.
Which means I'll send you a modified FindQt4.cmake and you tell me whether it 
still works on the Mac.
The main difference now is the way how libs are found, most of the rest is 
mostly synced now.

> > I'm sure I'm oversimplifying this but I'd really like to see us eliminate
> > some of this duplication by merging our fixes upstream, fixing the
> > modules outside of the Find*.cmake files whenever possible, removing the
> > versions that our provided by the minimum version of CMake we depend on
> > (assuming they work fine) and/or replacing them with the upstream CMake
> > versions to provide some easier merging.
> >
> > Any thoughts/suggestions on this? Can anyone suggest a step-by-step guide
> > that I can use to do this?

I'm all for it.
But it has to be done carefully, and the merging may have to be done in both 
ways, and on the KDE side I'm the only one (oh, wait, Marcus Hanwell now 
too...) with write access to the CMake repository.

I would be very happy over patches which sync Find*.cmake files in KDE with 
the ones in CMake and which break neither of the two.
I can then go and commit them on the cmake side if they are ok.

> > I'm not on kde-buildsystem any more so please CC me in our your replies.
>
> Thats easy: Create a diff, find out why the changes are needed, report an
> upstream bug in cmake's bugtracker with the patch(es). Then wait until a
> CMake release is available with the fixes.
>
> And at that point comes the problem: You need to convince everybody that we
> need to depend on the new cmake version. Thats a requirement you cannot
> easily change, we've only raised that requirement once since the KDE 4.0
> release.

Well, twice during one cycle, and I was yelled at for that :-)
But I still think it was a good decision to do it twice during that cycle, 
which means for outside developers only once.

Maybe we can think after 4.4 whether there are reasons to increase the 
required version. We'll need a rough survey which version distributions are 
shipping.

Alex