[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: branches/KDE/4.3/kdelibs/nepomuk/core
From:       Brad King <brad.king () kitware ! com>
Date:       2009-06-26 21:13:53
Message-ID: 4A453A11.3000204 () kitware ! com
[Download RAW message or body]

Andreas Pakulat wrote:
> On 26.06.09 12:56:09, Brad King wrote:
>> Andreas Pakulat wrote:
>>> 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)
>> We've already anticipated the case of importing from a project that
>> uses different configurations:
>>
>> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
>>
>> An imported configuration is chosen for a given local configuration
>> as follows:
>>
>> 1.) Check for MAP_IMPORTED_CONFIG_<LOCAL> property.  If set, one of
>>      the listed configurations must be available or it is not found.
>> 2.) Check for an exact-match for the <LOCAL> configuration name.
>> 3.) Accept any available imported configuration.  The lack of any
>>      MAP_IMPORTED_CONFIG_<LOCAL> property indicates any config is
>>      acceptable.
>>
>> Unfortunately the MAP_* properties must be set by the importing
>> project on every imported target.  I needed to gain experience
>> with a real project facing this problem before designing a simple
>> way to set all these properties.
> 
> I don't think I can understand the reasoning for this being explicit
> (except on windows where there's a real problem mixing libs from
> differing configs).

Windows is a first-class platform for CMake.
Our interface must support all platforms.

Anyway, the mapping does not *have* to be explicit.  The default
is to fall through to #3 and choose any available configuration.
We *permit* the explicit mapping for those that need to deal with
incompatible configurations.

The question in this thread is why don't all configurations just
follow #3 and accept DEBUGFULL?  David: In your 'kdepim' source
try adding the code

   get_property(loc TARGET KDE4__nepomuk PROPERTY LOCATION_DEBUG)
   message("neopumk=[${loc}]")

where "KDE4__nepomuk" is the name of the target on which that
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGFULL property you posted
was set.  What does it print?

 > Lets take KDevelop and the KDevPlatform module. The
> latter has quite some libraries in it, one of them may link against
> kdecore+kdeui+kfile and has all three of them in its link-interface
> (because it actually has one symbol from kfile in one of the methods in
> it). Now there's this plugin, it uses the library, but itself it only
> uses symbols from that library, kdeui and kdecore. Hence it looks to be
> fine, but a linker that is as strict as MSVC's or gold's will probably
> complain about the missing kfile library when linking.
> 
> Hence this plugin would need to set the above mentioned variable on
> Linux/Unix/Mac. Along with all other plugins and all other apps etc.

What does this have to do with imported configuration matching?

Your example appears to be asking about LINK_INTERFACE_LIBRARIES.
The link interface doesn't *have* to be set explicitly, and the
default is to include all the libraries to which a target links.
The link interface is an optimization to reduce dependencies.

-Brad
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

[prev in list] [next in list] [prev in thread] [next in thread]