From kde-buildsystem Mon May 19 23:13:27 2008 From: Modestas Vainius Date: Mon, 19 May 2008 23:13:27 +0000 To: kde-buildsystem Subject: Re: Reducing excess linkage - cmake 2.6 IMPORTED targets and Message-Id: <200805200213.35597.modestas () vainius ! eu> X-MARC-Message: https://marc.info/?l=kde-buildsystem&m=121123884606350 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0330323687==" --===============0330323687== Content-Type: multipart/signed; boundary="nextPart1763790.Ao0r0PBgaM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1763790.Ao0r0PBgaM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, 2008 m. May 20 d., Tuesday, Alexander Neundorf ra=C5=A1=C4=97: > What would you think about installing a KDELibsDependencies.cmake with > different contents ? > This could be done either by: > -postprocessing the file created from kdelibs by the distros > or by I don't quite understand what you want to gain by postprocessing. It looks = way=20 more hackish than doing it the proper cmake 2.6. > -creating a different file in kdelibs (problem may be the different > debug/optimized versions of the libs, but then again, this should matter > only for windows, right ?) Well, that's not a bad idea. kdelibs and kdepimlibs can generate two=20 dependency files with cmake 2.6: 1) Old with _LIB_DEPENDS. 2) New with IMPORTED targets and LINK_INTERFACE_LIBRARIES in effect. Then whichever to use could be chosen at build time of each KDE package wit= h a=20 standardised -D switch to cmake (e.g. -DUSE_LINK_INTERFACE=3Dtrue).=20 Distribution packages will pass the option to cmake to enable the new way=20 whereas Joe Average will `cmake . && make && sudo make install' and the bui= ld=20 process will use the old evil, but compatible way. Hence you get no bug=20 reports about linking failures from inexperienced users, but distribution=20 maintainers can still use the fixed build system. 1) People who are not interested won't use the feature and even won't notic= e=20 that someting has changed (old way stays default even on the distro using t= he=20 new way to build its official packages). 2) People who are interested will provide patches for KDE developers. We at= =20 Debian already have patched all official modules. We could sumbit patches n= ow =20 but we need an official macro which would not set LINK_INTERFACE_LIBRARIES = on=20 the target unless "the new way" is enabled. The point 2) from my initial ma= il=20 is very important too. > This solution would have the advantage that it would give the same results > with cmake 2.4.x and 2.6.x, which would be a big advantage. Even if you do postprocessing, other developers will _still have to patch_= =20 numerous target_link_libraries(), so why not specify =20 link_interfaces_libraries (via some macro probably) at the same time? I don= 't=20 think you should waste time and effort to solve excess linkage problems for= =20 cmake 2.4 users. All new distro releases will not include it anyway. The ti= me=20 should be better spent supporting a proper solution as an alternative to ha= ve=20 it ready as default for KDE 4.2. =2D-=20 Modestas Vainius --nextPart1763790.Ao0r0PBgaM 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) iD8DBQBIMgmfHO9JRnPq4hQRAqdrAKCe60KePMRInIqRRVX1LqqX5lbf0wCeLjQV Wia5sLE3OD+kMohYdgfmZX4= =2Zg1 -----END PGP SIGNATURE----- --nextPart1763790.Ao0r0PBgaM-- --===============0330323687== 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 --===============0330323687==--