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

[Modestas Vainius]

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.

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

Then whichever to use could be chosen at build time of each KDE package with a 
standardised -D switch to cmake (e.g. -DUSE_LINK_INTERFACE=true). 
Distribution packages will pass the option to cmake to enable the new way 
whereas Joe Average will `cmake . && make && sudo make install' and the build 
process will use the old evil, but compatible way. Hence you get no bug 
reports about linking failures from inexperienced users, but distribution 
maintainers can still use the fixed build system.

1) People who are not interested won't use the feature and even won't notice 
that someting has changed (old way stays default even on the distro using the 
new way to build its official packages).
2) People who are interested will provide patches for KDE developers. We at 
Debian already have patched all official modules. We could sumbit patches now  
but we need an official macro which would not set LINK_INTERFACE_LIBRARIES on 
the target unless "the new way" is enabled. The point 2) from my initial mail 
is very important too.

> 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 problems for 
cmake 2.4 users. All new distro releases will not include it anyway. The time 
should be better spent supporting a proper solution as an alternative to have 
it ready as default for KDE 4.2.

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20080520/b055117d/attachment.pgp