branches/KDE/4.3/kdelibs/nepomuk/core

[Andreas Pakulat]

On 26.06.09 16:36:50, David Faure wrote:
> On Friday 26 June 2009, Brad King wrote:
> > Andreas Pakulat wrote:
> > > So maybe link-interface-libs really only works within the same cmake
> > > project (I've always wondered where cmake stores this information so that
> > > it works across projects)?
> > 
> > The LINK_INTERFACE_LIBRARIES property for a target is recorded when
> > the target is installed by install(TARGETS) with the EXPORT option.
> > The EXPORT option associates the installation rule with a named
> > export group.  Later the install(EXPORT) command installs a .cmake
> > file containing rules to create IMPORTED targets from their installed
> > locations.  See this page for details:
> > 
> >    http://www.cmake.org/Wiki/CMake_2.6_Notes
> > 
> > The IMPORTED targets have IMPORTED_LINK_INTERFACE_LIBRARIES properties
> > which contain their link interfaces.
> 
> >From my kde install dir:
> 
> KDELibs4LibraryTargets-debugfull.cmake says:
>   IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGFULL "/d/kde/src/4/qt-copy/lib/libQtCore.so;-lpthread;KDE4__kdecore;KDE4__kdeui;/d/kde/inst/kdesupport-for-4.3/lib/libsoprano.so"
> which looks ok.
> Hmm, does it? The _DEBUGFULL appended to the name looks suspicious;
> if kdepim isn't compiled in debugfull then I suppose it won't be looking for this property?? My kdepim uses debug.
> I don't understand why the lib targets are build-type dependent...

Supposedly because the differing build-types may produce differing libs and
more importantly those libs might not be compatible. For example on Windows
a debug-compiled library won't work in a release-app as app and lib will
use different, incompatible versions of the C runtime.
 
> (Also ./KDELibs4LibraryTargets.cmake exists and doesn't contain the above;

But at its end it reads all XXXTargets-*.cmake files and hence the
_DEBUGFULL properties get set.

The cmake manpage pretty clearly explains what you're seeing here, the
_<CONFIG> versions correspond to the config of the project into which the
library is imported. Which totally makes sense, but also means you have to
build the whole stack with the same config option (which basically means
enforcing a limiation that comes from one platform onto all others)

I guess we need to report this with the CMake folks as these files are
auto-generated by CMake and hence we don't have control over it. Basically
CMake should simply additionally set the properties without the _<CONFIG>
prefix, so there exists a fallback in case there's no _<CONFIG>-variable
that matches the current projects config.

Andreas

-- 
Good day to deal with people in high places; particularly lonely stewardesses.