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

[Alexander Neundorf]

On Tuesday 01 July 2008, Dirk Mueller wrote:
> 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.

I'd prefer to completely switch to the new style as soon as possible, once 
this is done, this macro is useless.

> > 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.

Yes, it just encapsulates a temporary experimental ifdef, which should be the 
default (and only) option as soon as possible, and still we would have to 
keep it.

> > 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.. 

Actually, I'd like to break not a single build.
OTOH, we could declare it a bug in KDE 4.0 and do it the new way starting with 
4.1 and requiring apps to be fixed.
But adding a public macro now for 4.1 and removing it in 4.2 or 4.3 again 
doesn't sound good to me.

> > 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.

Ok.

> 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?

It would be nice to have it done for the 4.1 release, so that we don't have to 
figure out which linking style was used when somebody reports a problem with 
linking.

So, if the transition period is until 4.1, then I'd go for the "rename the 
target property" style, otherwise probably the macro (prefixed with an 
underscore so nobody can complain if it goes away) is the better way.

Alex