Hello, It's a follow up for http://bugs.kde.org/show_bug.cgi?id=160976. Please read this bug report for the background on the issue. Short description of the patches can be found in the bug report too.
First of all, the patch (97th) [1] should be compatible with cmake 2.4.x. If kdelibs is compiled with cmake 2.4.x, the "old way" of adding numerous (but in most cases excess which is the problem being fixed here) libraries in target_LIB_DEPENDS to respective KDE4_*_LIBS is used. Then either cmake 2.4 or 2.6 can be used to build other KDE modules and everything should build fine without a single change. However, if cmake 2.6 is used to compile kdelibs, the new way of exporting dependences (IMPORTED targets) is used. However, in this case other KDE4 project cannot be built with cmake 2.4 against such kdelibs, cmake 2.6 becomes a minimum requirement. Well, resolution of the bug in question has been delayed by Alex, but, in my opinion, it's a mistake. Impact of this change is likely to be very broad because it might affect almost all KDE4 based software (official and 3rd party) (a real impact depends on what LINK_INTERFACE_LIBRARIES will be set to for kdelibs core libs), so this transition cannot be completed in a day. The earlier you start doing the changes, the better. Advantages: 1) As Alex said previously, cmake 2.6 is not stable yet (but will be soon), so most of cmake 2.6 users are probably developers. Fortunately, developers are the target audience to fix TARGET_LINK_LIBRARIES() and add LINK_INTERFACE_LIBRARIES for library targets (the latter is only needed if lib is heavily depended on by other targets) in their CMakeLists.txt's. What's more and what's very important, the changes they make will be backwards compatible with cmake 2.4. 2) Developers of kdelibs core libraries need to decide/discuss what libs to put in LINK_INTERFACE_LIBRARIES. Preliminary and probably a bit wrong stuff is in my 98 patch [2]. However, kdelibs (cmake 2.6+new way) builds with that patch. 3) Finally, if kdelibs is build with cmake 2.4, the user is not affected at all due to fallback to the previous way. Maybe you can even implement an option to disable "the new way" on cmake 2.6, but I suggest "the new way" to be enabled by default when kdelibs is compiled with cmake 2.6, otherwise just a few other developers will notice linkage problems. To sum up, cmake 2.4 users don't "lose" anything and this build system migration is done incrementally as more and more devs start using cmake 2.6 to build kdelibs and fix TARGET_LINK_LIBRARIES() themselves or more users complain about linking failures. This transition should be started by completing point 2. P.S. My proposal does not completely solve excess linkage problem, however it improves situation significantly. To solve the issue completely, recursive linking should be "disabled" by setting LINK_INTERFACE_LIBRARIES to "" for almost all libs. Such change would break build of almost everything though). See [3] and [4] for more information. 1. http://svn.debian.org/wsvn/pkg-kde/branches/kde4/packages/kdelibs/debian/patches/97_use_imported_targets_with_cmake26.diff?op=file&rev=0&sc=0 svn://svn.debian.org/svn/pkg-kde/branches/kde4/packages/kdelibs/debian/patches/97_use_imported_targets_with_cmake26.diff 2. http://svn.debian.org/wsvn/pkg-kde/branches/kde4/packages/kdelibs/debian/patches/98_link_interface_libraries.diff?op=file&rev=0&sc=0 svn://svn.debian.org/svn/pkg-kde/branches/kde4/packages/kdelibs/debian/patches/98_link_interface_libraries.diff 3. http://public.kitware.com/Bug/view.php?id=6846 4. http://www.vtk.org/Bug/view.php?id=3490 -- Modestas Vainius <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
