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

[Dirk Mueller]

On Friday 27 June 2008, Alexander Neundorf wrote:

> > +macro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES _target _interface_libs)
> > +   if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT  AND  UNIX )# AND NOT APPLE)
> > +      set_target_properties("${_target}" "${_interface_libs}")
> > +   endif(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT  AND  UNIX)#  AND NOT
> > APPLE) +endmacro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES)
> Hmm, I don't like that.
> If we do it, I'd prefer that we do it only this new way, i.e. all KDE
> builds will use the new style.

I don't get what you mean here. 

> Adding the macro to KDE4Macros.cmake means that we have to maintain it for
> all of KDE 4.x.

there is not an awful lot to maintain with this macro.. it just encapsulates 
the experimental ifdef. 

> I'd prefer to see it as a temporary hack during the transition.

if we care that much about not breaking the build for 3rd parties, then we 
have to keep the building type configurable.. and that even without recompiling 
kdelibs (which is not possible at the moment). e.g. if you run into a linking 
issue due to LINK_INTERFACE_LIBRARIES, a -DKDE4_COMPAT_LINK_INTERFACE=ON (or 
something like that) must restore the old behaviour without having to 
recompile underlying modules. 

the only way to implement that would be to write both dependency styles to the 
Dependencies.cmake file, and it select the right variant via some if() magic - 
and thats exactly where such a macro that hides all the uglyness helps. 

> How about prefixing it with an underscore to make clear it's no public
> macro ?

fine with me as well.

> And additionally moving it out of KDE4Macros.cmake into
> kdelibs/CMakeLists.txt, so it stays within kdelibs. We might need to copy
> it ti kdepimlibs. Is this actually important also for libraries in other
> modules ? 

yes, I use it for processui/core in ksysguard and other libraries in 
kdebase/apps/lib and kdebase/workspace/libs. all other modules also contain 
libraries (e.g. kdegraphics/libs) etc. 

I assume however that   modules outside kdelibs,kdebase only need minimal 
patching, but I'm not there yet. 

> Or, instead of using a macro, how about this:
> if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT  AND  UNIX )
>    set(DISABLE )
> else(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT  AND  UNIX )
>    set(DISABLE DISABLED_PROPERTY_)
> endif(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT  AND  UNIX )
>
> and then do
>
> set_target_properties(khtml PROPERTIES VERSION
> ${KDE_NON_GENERIC_LIB_VERSION} SOVERSION ${KDE_NON_GENERIC_LIB_SOVERSION}
>            ${DISABLE}LINK_INTERFACE_LIBRARIES
> "kparts;kjs;kio;kdeui;kdecore")
>
> So if the option is enabled, DISABLE is empty and the correct property is
> set, otherwise a useless property is set.
> Still this should be done only for the transition period I'd say.

I think thats even harder to understand than a custom kde4_ macro, but it 
would also be fine with me. 

How long does the transition period last in your opinion? until KDE 4.1 
release or KDE 4.2 release?

Greetings,
Dirk