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

[Leo Savernik]

Am Montag, 30. Juni 2008 schrieb Modestas Vainius:
> 2) KDE 4.1 branch will be more compatible with older 3rd party kde4  
> applications. Please have in mind that this experimental linking will
> probably be enabled by some distros (Debian at least however we are not
> going to ship full KDE 4.1 in upcoming stable, only everything up to
> runtime) by default.

What's the impact on BC by these changes? As I understand your explications, 
an App foo linking to liba which transitively links to libb, where foo 
accesses symbols of both liba and libb, currently works under KDE 4.0.

For KDE 4.1 we want to make linkage explicit (which I consider a good idea per 
se). When running foo built against KDE 4.0's liba under KDE 4.1, it will 
bomb out as it cannot resolve the symbols of libb anymore.

Can this happen with your proposed changes? This would be BIC. Otherwise, if 
linkage errors only occur on build time, it's only a mild form of SIC, which 
we could justify.

>
> > 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).
>
> Everything Qt/KDE based (99,99%) needs QtCore, as almost all KDE apps need
> kdecore. That is not the case with QtDBus what you effectively state here.

If somebody intends to write a hypothetical kde command line app depending 
only on qtcore and kdecore without gui and without dbus, loading and 
execution shouldn't suffer by dragging in QtDBus. I think KDE 4 *should* 
support lean and fast command line apps.

mfg
	Leo