On 6/19/2016 9:17 PM, Mike Gelfand wrote: > > The suggested way to deal with this seems to be to use > MAP_IMPORTED_CONFIG_<CONFIG> target properties, but I suppose it should > only (?) be used when imported target (or target it's being linked to) > has non-standard configurations, which isn't so in this case. >
Alternatively, maybe it makes sense for FindBoost to simply set all configurations explicitly? By iterating over CMAKE_CONFIGURATION_TYPES (or inspecting CMAKE_BUILD_TYPE for single-config generators) and using the global property DEBUG_CONFIGURATIONS to determine whether a given configuration needs the debug or the release binaries. I'm still unsure what to make of the current fallback-to-first-configuration behavior. I did not find this mentioned anywhere in the docs, so I guess it's not a behavior one should rely upon? I was wondering whether it would make sense to properly define what CMake does in such a case. In particular since, as you mentioned, package configuration files might already rely on some assumptions there. Best regards, Andreas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
