From kde-buildsystem Wed Apr 30 14:57:58 2008 From: Modestas Vainius Date: Wed, 30 Apr 2008 14:57:58 +0000 To: kde-buildsystem Subject: Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and Message-Id: <200804301758.05975.modestas () vainius ! eu> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=120956754120493 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1558037962==" --===============1558037962== Content-Type: multipart/signed; boundary="nextPart1705040.Q3XBbYBuA5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1705040.Q3XBbYBuA5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, 2008 m. April 28 d., Monday, Alexander Neundorf ra=C5=A1=C4=97: >Pro: >-your patches look good >-I think you are right Great. >-cmake 2.6.0 is not released yet and we are already at alpha1 stage of KDE= =20 4.1 Yep, but it is very very near. > Depending on how we deal with the compatibility problem, I'd like to do > this once trunk is open for KDE 4.2 and require cmake 2.6.x by then, so > *every* developer will notice when something breaks. Then we'll also have > time to make sure at least the sources in KDE svn build properly. I understand your concerns. You have to make sure nothing breaks on more=20 platforms than GNU/Linux. Then could we ask to make that "new way" as an=20 option (non-default) for kdelibs with cmake 2.6? This way we can ask other= =20 KDE developers to accept patches fixing target_link_libraries() (they would= =20 be harmless for the default way). I especially want point 2=20 (LINK_INTERFACE_LIBRARIES) to be done by KDE developers (for kdelibs and=20 kdepimlibs at least). Again, this can be done via some macro which would be= =20 noop if the option is not enabled. We are doing this, because so much excess interlinking hurts quality of Deb= ian=20 archive and makes various transitions involving KDE painful. Currently, we= =20 wouldn't very mind excess linkage with QtNetwork, QtXml, QtDBus, QtSvg, kde= ui=20 (via kio) etc. (it would be nice to have that cleaned up too), but we=20 definitely must get rid of -lX11 -lz -lldap -lXext etc (which require build= =20 dependences of their own). I could rewrite the 97 patch making the "new way" depend on the kdelibs swi= tch=20 (e.g. -DUSE_LINK_INTERFACE) (which would be disabled by default) if you're= =20 going to accept it. Even if you prefer official KDE 4.1 to use old way,=20 Debian will use the new way, so you can be sure it will be rock solid for K= DE=20 4.2 on GNU/Linux. =2D-=20 Modestas Vainius --nextPart1705040.Q3XBbYBuA5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIGIj9HO9JRnPq4hQRAgrZAJwKJJdwJQAh80cf0H5qVCFDRBtV9wCfbvnJ N2tKjMgj/KjkGsvcOvCBjgM= =fTjQ -----END PGP SIGNATURE----- --nextPart1705040.Q3XBbYBuA5-- --===============1558037962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem --===============1558037962==--