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