conan: [question][1.55.0] "CMakeDeps" doesn't provide `IMPORTED_LOCATION[_]` target properties for its generated Imported Targets?
Problem Description
This issue is related to the one I posted before, which was closed with the new release version 1.55.0:
In short, the problem mentioned in the above issue is that “CMakeDeps” generator doesn’t provide the following target properties for its generated Imported Targets:
However, it seems that this problem is still not solved after conducting some experiments, https://github.com/conan-io/conan/issues/12077#issuecomment-1324031251.
What do I miss? If I do miss somehting in the demo, can you provide a correct demonstration?
Thanks.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 2
- Comments: 30 (13 by maintainers)
@jcar87, @memsharded: It seems as if there’s 2 issues here:
The question then is - should Conan produce targets that work as expected with CMake or should CMake fix this apparent oversight or both?
The problem is that this is not really related to the original ticket, so it was confusing to me, it is difficult to track things, and easy to assume 2.0 for new reports that are not that direct follow up from the previous conversation.
package_type
,traits
etc are not going to help at all for 1.X, they are only used in 2.0 resolution.It is true that Conan 1.X is not generating the
_BIN_DIRS
variables inCMakeDeps
, only 2.0 does it. I’d say the/bin
hardcoding is a good workaround in the meantime, asbin
being the bindirs folder is practically 100% guaranteed.Sadly I too have this problem, so for now I’m using a workaround as I only need to install 1 .dll that is also managed by me. If anyone needs or wants to jump into the rabbit hole though, I’m posting a very useful CMake command that I’ve found today to dump all the properties of a target. These of course are many of the available properties of a target, but you get the idea:
Take Protobuf for example.
protobuf::libprotoc
declared by Official Config Files isSHARED IMPORTED
.protobuf::libprotoc
declared by CMakeDeps isINTERFACE IMPORTED
.Screeshots:
@jcar87
According to the CMake Docs, it seems that the reason is because CMakeDeps declares those Imported Targets as
INTERFACE IMPORTED
. Therefore, they cannot carry the following target properties, which store the information of DLLs on disk:I was wondering why not just declare them as:
STATIC IMPORTED
for “Static” LibrariesSHARED IMPORTED
for “Shared” LibrariesIf I didn’t understand wrong, the
INTERFACE IMPORTED
is designed for “Header-Only” Libraies. Is there any reason why CMakeDeps insists on declaring all the Imported Targets asINTERFACE IMPORTED
?@hwhsu1231 thanks so much for providing this example.
The internal targets (generated by CMakeDeps) that would be transitively linked by
Qt6::Core
do have those properties set - CMake is able to walk through the dependency graph in order to resolveTARGET_RUNTIME_DLLS
. So in this case, I don’t think the issue has to do withQt6::Core
not having those properties.From what I can see from the documentation here: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#genex:TARGET_RUNTIME_DLLS
I believe the issue here would by cause by the internal targets generated by
CMakeDeps
not explicitly defining that the targets areSHARED
. We will investigate this!