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

[Alexander Neundorf]

On Tuesday 20 May 2008, you wrote:
> Hi,
>
> 2008 m. May 20 d., Tuesday, Alexander Neundorf rašė:
> > What would you think about installing a KDELibsDependencies.cmake with
> > different contents ?
> > This could be done either by:
> > -postprocessing the file created from kdelibs by the distros
> > or by
>
> I don't quite understand what you want to gain by postprocessing. It looks
> way more hackish than doing it the proper cmake 2.6.

Yes, I know.

> > -creating a different file in kdelibs (problem may be the different
> > debug/optimized versions of the libs, but then again, this should matter
> > only for windows, right ?)
>
> Well, that's not a bad idea. kdelibs and kdepimlibs can generate two
> dependency files with cmake 2.6:
>
> 1) Old with _LIB_DEPENDS.
> 2) New with IMPORTED targets and LINK_INTERFACE_LIBRARIES in effect.

Please update kdelibs from svn (or at least kdelibs/CMakeLists.txt and the new 
kdelibs/CreateKDELibsDependenciesFile.cmake).

I implemented it a bit (quite) different.
If you enable the new option KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT, the target 
property LINK_INTERFACE_LIBRARIES will be queried for all library targets and 
set()-commands will be generated after the ones from 
export_library_dependencies() so they override these values.
This should be very compatible to the cmake 2.6 behaviour, where the full list 
of libs is used if this property hasn't been set.
This means we will have identical behaviour with cmake 2.4 and 2.6 and once we 
require cmake 2.6 the work done now is what we will need then too (and adding 
the exports). 

This means to make this work for you you have to set the 
LINK_INTERFACE_LIBRARIES property for the library targets. This shouldn't be 
a problem no matter whether you are using cmake 2.4.x, cmake 2.6.x or whether 
this option is enabled or disabled.
If it is disabled, the property will be set but it will be completely ignored.
If it works for you, and also Dirk agrees, and also the release team agrees, 
I'd enable this always under UNIX (not APPLE).

> > This solution would have the advantage that it would give the same
> > results with cmake 2.4.x and 2.6.x, which would be a big advantage.
>
> Even if you do postprocessing, other developers will _still have to patch_
> numerous target_link_libraries(), so why not specify
> link_interfaces_libraries (via some macro probably) at the same time? I
> don't think you should waste time and effort to solve excess linkage

Well, supporting cmake 2.4 is not wasting time, this is the version we require 
and which is shipped currently by all distros.

Alex