branches/KDE/4.3/kdelibs/nepomuk/core
Brad King
brad.king at kitware.com
Fri Jun 26 18:56:09 CEST 2009
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
More information about the Kde-buildsystem
mailing list