CMakeDeps managing CMAKE_MAP_IMPORTED_CONFIG_XXX - #12049
Conversation
memsharded
left a comment
There was a problem hiding this comment.
Looking good, a bit risky, but IMPORTED is what should be used, and config suffix too
There was a problem hiding this comment.
This looks good to me with two caveats:
-
Without this fix, a situation where a consumer project as "Debug" as the build type, and the dependencies where installed as "Release" - CMake gives you a warning (or an error dependency on policy). The warning is indicative of the mismatch and the potential problems. With this fix in the same situation, there's no longer a CMake warning, but compilation will fail. - this may make the user experience confusing.
If the consumer project does not explicitly do mapping, the observed behaviour is the same with and without this PR. -
The
CMAKE_MAP_IMPORTED_CONFIG_in the consumers side accept, as value, a list, not just a single config. If we have a situation where a consumer runsconan installfor multiple build types, and the CMake side has a configuration that can be satisfied by "any" of those - they could express something likeset(CMAKE_MAP_IMPORTED_CONFIG_RELEASE Release RelWithDebInfo MinSizeRel Debug ""). I'd say this is very unusual, but as explained in this CMake issue, that would cause multiple generator expressions to be matched, likely resulting in libraries from different build times to be simultaneously linked...
Changelog: Bugfix: The
CMakeDepsgenerator was not working properly when the consumer maps configurations of the dependencies usingCMAKE_MAP_IMPORTED_CONFIG_XXX.Docs: conan-io/docs#2826
Close #12041