Current kdelibs linker error

[Alexander Neundorf]

On Tuesday 22 July 2008, Christian Ehrlicher wrote:
>  Von: Ralf Habacker
>
> > Ralf Habacker schrieb:
> > > Carlo schrieb:
> > >> 2008/7/22 Christian Ehrlicher <Ch.Ehrlicher at gmx.de>:
> > >>> Hi,
> > >>>
> > >>> Since today I get linker errors in kdelibs due to missing kdewin32
> > >>> library.
> > >>> cmake found it and kdecore is linking against it.
> > >>>
> > >>> Maybe kdecore_OPTIONAL_LIBS is not added to the cache anymore?
> > >>>
> > >>> Thx,
> > >>> Christian
> > >>
> > >> So it's not just my problem, saroengels told me to add
> > >> ${KDE4_KDECORE_LIBS} and it seems to works, kross instead needs
> > >> ${KDE4_KDEUI_LIBS}
> > >
> > > There are more targets broken - I fixed this general with the appended
> > > patch.
> >
> > I have to correct: I need to add KDEWIN32_LIBRARIES to KDE4_KIO_LIBS too
> > to be able to build kbuildsycoca4.
>
> Plz wait until Alex answered.

..and here comes my answer ! ;-)

I broke it yesterday, I fixed it now again.

ASAP we'd like to use a reduced "link interface" for the shared libs under 
Linux (and probably all other UNIX-like OSs). I don't know about Windows.
What does this mean ?
By default cmake links targets which link to a library also to all libraries 
this library is linked against.
So if you link kfoo against kdeui, you will automatically also link against 
kdecore, since kdeui has been linked against kdecore.
While this is convenient, this has two drawbacks (at least on Linux):
-it increases application startup time, since more libraries have to be 
initialized and loaded immediately (if I understood Dirk correctly)
-binary packages have more dependencies than strictly necessary

This can be changed by setting the LINK_INTERFACE_LIBRARIES target property. 
Here you can define which libraries will be linked automatically when linking 
against a target.
Example in kdecore:

set_target_properties(kdecore PROPERTIES 
                        VERSION ${KDE_NON_GENERIC_LIB_VERSION} 
                        SOVERSION ${KDE_NON_GENERIC_LIB_SOVERSION}
 ${KDE4_DISABLE_PROPERTY_}LINK_INTERFACE_LIBRARIES "${QT_QTDBUS_LIBRARY};
${QT_QTCORE_LIBRARY}"
                     )

This sets the "link interface" to QtDBus and QtCore for kdecore. So everything 
linking to kdecore will also be linked against these two libraries (but not 
more, as e.g. zlib).
Now you can see that the property LINK_INTERFACE_LIBRARIES is prefixed with 
${KDE4_DISABLE_PROPERTY_} . 

This variable is set in FindKDE4Internal.cmake:
set(KDE4_DISABLE_PROPERTY_ "DISABLED_")

if(UNIX )# AND NOT  APPLE)
   option(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT "Enable the experimental reduced
                                               library exports" FALSE)
   # If enabled, make it empty, so the property will keep it's actual name.
   # and the LINK_INTERFACE_LIBRARIES property will be set.
   if (KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT)
      set(KDE4_DISABLE_PROPERTY_ )
   endif (KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT)
endif(UNIX)#  AND NOT  APPLE)


So by default it will be "DISABLED_", so the command will resolve to 

set_target_properties(kdecore PROPERTIES 
                        VERSION ${KDE_NON_GENERIC_LIB_VERSION} 
                        SOVERSION ${KDE_NON_GENERIC_LIB_SOVERSION}
 DISABLED_LINK_INTERFACE_LIBRARIES "${QT_QTDBUS_LIBRARY};${QT_QTCORE_LIBRARY}"
                     )


Now DISABLED_LINK_INTERFACE_LIBRARIES is no known cmake target property, i.e. 
by default just that unknown (custom) target property will be set, which is 
not used anywhere. 
If you are not on Windows you get an option 
KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT. If you enable this, 
KDE4_DISABLE_PROPERTY_ will be set empty and so the actual real target 
property will be set.
This logic was broken for Windows yesterday, I fixed it now.
The linker errors you saw were the results of that. Some targets rely on the 
libs which are linked automatically. This can be considered a bug and should 
be fixed by adding the missing libraries to the TARGET_LINK_LIBRARIES() 
commands.

Are you on Windows also interest in this functionality ?
Currently it is inside an "IF(UNIX)".

Alex