On 1/25/2012 1:50 AM, Michael Wild wrote:
As to why you do get a result for IMPORT_LOCATION, I think you've accidentally hit some backward compatibility code, see http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=refs/tags/v2.8.7#l2685. That nugget tries to handle<CONFIG>_LOCATION, and in your case<CONFIG> is "IMPORT". AFAICS there must be something wrong in the cmTarget::ComputeImportInfo(...) function, since for every non-existing configuration it returns the data from the first existing configuration it finds...
Thanks for tracking that down. The behavior of ComputeImportInfo is intentional: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=refs/tags/v2.8.7#l4194 The idea is that the project that exported its targets and the project that is loading the imported targets may not use the same set of build configuration choices. Therefore the MAP_IMPORTED_CONFIG_<CONFIG> property may be set by the importing project to choose how its configs map to the imported project's configs: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG When there is no mapping and the configuration requested has no exact match then we have no choice but to assume that the importing project does not care which configuration it gets. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
