Reducing excess linkage - cmake 2.6 IMPORTED targets and LINK_INTERFACE_LIBRARIES for kdelibs

[Modestas Vainius]

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 <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080428/5b4b4bb0/attachment.pgp