Hi Folks, For reference, there is an issue tracker entry for this problem:
https://gitlab.kitware.com/cmake/cmake/issues/16091 Similar alternatives have been discussed there. On 06/20/2016 01:32 AM, Andreas Weis wrote: > 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 That property is meant for client code to set when it has a different set of configurations than those imported. Technically that is true here, but CMake should have better default behavior for the builtin configurations like RelWithDebInfo. > 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. There is discussion about this in the above-linked issue. I think switching the order of configurations is a good solution to use until the alternatives can be considered: FindBoost: Make imported targets fall back to `Release` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9fca42f Thanks, -Brad -- 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
