[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 16:56:09
Message-ID: 4A44FDA9.7010102 () kitware ! com
[Download RAW message or body]

Andreas Pakulat wrote:
> On 26.06.09 16:36:50, David Faure wrote:
>> I don't understand why the lib targets are build-type dependent...
> Supposedly because the differing build-types may produce differing libs

Correct.

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

Yes.

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

The auto-generated import rules can only be per-configuration.  They cannot
have a fallback.  There is no automatic safe way to choose one.  Besides,
the above algorithm already falls back to any available configuration.

So the question in this case is: why does step #3 of the above algorithm
not work?  I assume you're not setting any MAP_... property.  If anyone
tries to debug this, look at the cmTarget::ComputeImportInfo method of
the CMake source in "Source/cmTarget.cxx".

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