Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs

[Alexander Neundorf]

On Monday 30 June 2008, you wrote:
> Alexander Neundorf wrote:
> >> The only QtXml user is kross/core/action.h
> >> fromDomElement/toDomElement. I don't think this is enough to link all
> >> krosscore users against QtXml.
> >
> >Hmm, is it a real problem if QtXml is listed here ? It shouldn't add
> > more package dependencies (QtXml should be installed anyways when KDE4
> > is installed).
>
> That's not the point.
>
> The point is that most applications won't be using QtXml symbols, so they
> shouldn't be linking *directly* to QtXml. If they do use them, then they
> should link.
>
> >> > kio
> >> > LINK_INTERFACE_LIBRARIES "kdeui;kdecore;${QT_QTNETWORK_LIBRARY};
> >>
> >> ${QT_QTXML_LIBRARY}"
> >> Could you please justify QtNetwork and QtXml here? None of public kio
> >> headers need QtNetwork (actually, QtNetwork is not worth bundling with
> >> anything). QtXml users are kbookmark*.h (internal method) and
> >> davjob.h. In my opinion, they are not good enough reason to pull
> >> QtXml. Application can specify it manually. However, it is true that
> >> there will be relatively many linking failures due to missing QtXml.
> >
> >That's the justification. Avoiding too much breakage.
>
> I don't agree. If we do this at all, we should do the proper cleanup. If
> the application doesn't use QtDBus directly, they shouldn't link to
> QtDBus directly.
>
> Every application and library has to explicitly list all of its direct
> dependencies and only the direct ones. Anything else is an error.
>
> This interface stuff is just a convenience.

Yes.
But this would also mean that the LINK_INTERFACE would be completely empty for 
everything.
I think keeping some libs for convenience there is ok, as long as this doesn't 
result in bigger problems.
So I don't really see a problem in kdecore dragging in QtDBus (...having also 
the breakage in mind which removing too much will cause).

Alex