[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and
From:       Modestas Vainius <modestas () vainius ! eu>
Date:       2008-06-30 9:46:37
Message-ID: 200806301246.42658.modestas () vainius ! eu
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@vainius.eu>


["signature.asc" (application/pgp-signature)]

_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem


[prev in list] [next in list] [prev in thread] [next in thread]