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

[Andreas Hartmetz]

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.

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

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

> I remember that the second way was already discussed but I've forgotten the
> details and the outcome.
>