[Phonon] 0532638 This is a terrible hack to make phonon-xine findp

[Alexander Neundorf]

On Monday 27 December 2010, Andreas Hartmetz wrote:
> On Sunday 26 December 2010 10:05:40 Yury G. Kudryashov wrote:
> > Andreas Hartmetz wrote:
> > > On Saturday 25 December 2010 21:06:03 Yury G. Kudryashov wrote:
> > >> Andreas Hartmetz wrote:
> > >> >     I think FindPhonon.cmake being installed by kdelibs, into a
> > >> >     KDE-specific path, is the underlying problem that needs to
> > >> >     be fixed. Looks like a circular dependency of sorts to me.
> > >> >     We're going to see similar problems in the future with
> > >> > kdesupport fragmenting more and more.
> > >>
> > >> This way phonon-xine depend both on phonon and kdelibs (for
> > >> kde4-config). Why not just copy FindPhonon.cmake to phonon-xine and do
> > >> *not* install it?
> > >
> > > Because copying stuff around is always bad. It forces you to keep track
> > > of the copies in case something changes in the original.
> > > I am hoping for a solution with no such downsides.
> > > If I had copied FindPhonon.cmake into phonon-xine that might have been
> > > just good enough for everybody to continue ignoring the problem ;)
> > > The current hack is meant to be temporary and bad.
> >
> > Do you think that copying parts of FindKDE4{,Internal}.cmake and adding
> > kdelibs dependency is better than copying FindPhonon.cmake?
>
> I think it's worse, and it's supposed to be temporary.
> As I tried to say above, I added a hack that hopefully nobody will accept
> in the long run and fix it properly instead.

Best fix for now: include a copy of FindPhonon.cmake in phonon-xine.

> > I see two solutions:
> > 1. Push FindPhonon.cmake to the list of find modules installed by cmake.
>
> That would work, although it's a little strange to have to add everything
> to cmake proper. That's not modular. But it works without big downsides.

It needs somebody to volunteer for maintaining it once it is in cmake, i.e. to 
make sure it works for everybody and it keeps compatibility.
That's what I'm trying to do for the cmake modules we install from 
kdelibs/cmake/modules/.


> > 2. Create a kdesupport project for cmake macroses.
>
> Then we still have to find a good install path. May or may not be a
> problem.

With this we still have the same compatibility-keeping burden for the files 
contained in it as we have now for the cmake-files installed by kdelibs.

Well, maybe is moving kdelibs/cmake/modules/ to kdesupport/kdecmakemodules/ or 
something like this not such a bad idea after all...
But let's wait with this at least until 4.6 is out.

Alex