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

Modestas Vainius modestas at vainius.eu
Mon Jun 30 11:46:37 CEST 2008


Hi,

Monday 30 June 2008, Alexander Neundorf rašė:
> I think keeping some libs for convenience there is ok, as long as this
> doesn't result in bigger problems.
I agree with this but only for transitional period since it is getting very 
late for KDE 4.1. So I suggest the following. Lets do a proper clean up for 
trunk and fix target_link_libraries() for all modules. Once KDE 4.1 is 
branched, then apply a patch to the KDE 4.1 branch which adds *more excess* 
QT-KDE inter linkage to ensure better compatibility for the transitional 
period. This way:

1) Both trunk (upcoming KDE 4.2) and KDE 4.1 branch will benefit from fixed 
target_link_libraries(). Developers, using KDE trunk, will be able to fix 
their apps quickly.
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.

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

-- 
Modestas Vainius <modestas at vainius.eu>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080630/a4712c3f/attachment.pgp 


More information about the Kde-buildsystem mailing list