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

[Alexander Neundorf]

On Monday 28 April 2008, Modestas Vainius wrote:
> 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.

Here is what the cmake FAQ says:
http://www.cmake.org/Wiki/CMake_FAQ#Why_are_libraries_linked_to_my_shared_library_included_when_something_links_to_it.3F

Here is something from a discussion last summer with David and Thiago:
David's email:

On Tuesday 14 August 2007, Alexander Neundorf wrote:
> If you take a look at share/apps/cmake/modules/KDELibsDependencies.cmake, 
> 
> 
SET(kdecore_LIB_DEPENDS "/usr/local/lib/qt4/lib/libQtCore.so;-lpthread;/usr/local/lib/qt4/lib/libQtGui.so;
>                          /usr/local/lib/qt4/lib/libQtDBus.so;util;/usr/lib/libz.so;/usr/lib/libbz2.;
>                          resolv;/usr/lib/libXtst.so;")
> 
> 
> This is included in FindKDE4Internal.cmake, where the following is done:
> 
> set(KDE4_KDECORE_LIBS ${kdecore_LIB_DEPENDS} ${KDE4_KDECORE_LIBRARY} )
> Apart from the fact that ${kdecore_LIB_DEPENDS} should come after 
> ${KDE4_KDECORE_LIBRARY}
Only matters for static libs AFAIK.

> , this also means that every application which links  
> to kdecore via ${KDE4_KDECORE_LIBS}, also links to all libraries kdecore 
> links too.
OK

> So let's say kdeui also links to Blitz, and later on Blitz isn't used 
anymore 
> by kdeui, then which scenario is the one which can introduce problems ?
> 
> If the application is recompiled, there is no problem.
> If it is not recompiled, the app will still work because when it was linked 
it 
> was linked directly with Blitz.

This is good, no runtime surprises.

However there's still a case where things break: you upgrade kdelibs (and 
blitz isn't anymore
in the kdeui_LIB_DEPENDS), then you recompile the application (which still 
doesn't mention
blitz explicitely) -> link error.
But this is good I think. It breaks at linking (packaging) time (-> advanced 
users), not at runtime (-> joe user).

Thanks for the clarification of the cmake behavior, I hadn't realized that the 
mentionning
of the dependencies actually helps for what we want.

----------------------
Thiagos follow-up:
David Faure wrote:
>> If the application is recompiled, there is no problem.
>> If it is not recompiled, the app will still work because when it was
>> linked it was linked directly with Blitz.
>
>This is good, no runtime surprises.

You forgot the case where the application doesn't use Blitz, isn't 
recompiled and Blitz is simply gone.

In that case, the application will fail to load because a library it 
doesn't use isn't present anymore.

Of course, this won't happen with packaged applications because the 
package managers will track the dependency via soname and install Blitz. 
But advanced users who don't use package managers to install KDE will see 
this error.

-----------------------------------------

So it seemed to me the current behaviour was ok.
Can you give a concrete example of the problems the current behaviour causes ?

So here come some comments:
Pro:
-your patches look good
-I think you are right

Con:
-I think having two quite different builds for KDE (i.e. different linking 
when built using cmake 2.6 and 2.4) may become a serious maintainance problem 
(not everything will be tested in both versions, when somebody reports linker 
problems there are two different potential causes)
-cmake 2.6.0 is not released yet and we are already at alpha1 stage of KDE 4.1
-the patches kind-of break source compatibility, stuff which links with KDE 
4.0.x may not link anymore once this patch is applied


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.

Alex