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.

@memsharded @lasote

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)

Most upvoted comments

@jcar87, @memsharded: It seems as if there’s 2 issues here:

  1. Conan produces INTERFACE targets that then refer to the actual imported targets. This looks like a reasonable indirection to me, but the problem is that:
  2. CMake seems to assume that the referenced target will be the actual imported library/executable/whatever in all of its DLL-related helper functions (TARGET_RUNTIME_DLLS generator expression, install IMPORTED_RUNTIME_ARTIFACTS, etc) . This seems like it could be an oversight or bug?

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 in CMakeDeps, only 2.0 does it. I’d say the /bin hardcoding is a good workaround in the meantime, as bin 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:

include(CMakePrintHelpers)
cmake_print_properties(
    TARGETS myConanDep::myConanDep
    PROPERTIES
        IMPORTED
        IMPORTED_COMMON_LANGUAGE_RUNTIME
        IMPORTED_CONFIGURATIONS
        IMPORTED_GLOBAL
        IMPORTED_IMPLIB
        IMPORTED_IMPLIB_Debug
        IMPORTED_IMPLIB_Release
        IMPORTED_LIBNAME
        IMPORTED_LIBNAME_Debug
        IMPORTED_LIBNAME_Release
        IMPORTED_LINK_DEPENDENT_LIBRARIES
        IMPORTED_LINK_DEPENDENT_LIBRARIES_Debug
        IMPORTED_LINK_DEPENDENT_LIBRARIES_Release
        IMPORTED_LINK_INTERFACE_LANGUAGES
        IMPORTED_LINK_INTERFACE_LANGUAGES_Debug
        IMPORTED_LINK_INTERFACE_LANGUAGES_Release
        IMPORTED_LINK_INTERFACE_LIBRARIES
        IMPORTED_LINK_INTERFACE_LIBRARIES_Debug
        IMPORTED_LINK_INTERFACE_LIBRARIES_Release
        IMPORTED_LINK_INTERFACE_MULTIPLICITY
        IMPORTED_LINK_INTERFACE_MULTIPLICITY_Debug
        IMPORTED_LINK_INTERFACE_MULTIPLICITY_Release
        IMPORTED_LOCATION
        IMPORTED_LOCATION_Debug
        IMPORTED_LOCATION_Release
        IMPORTED_NO_SONAME
        IMPORTED_NO_SONAME_Debug
        IMPORTED_NO_SONAME_Release
        IMPORTED_OBJECTS
        IMPORTED_OBJECTS_Debug
        IMPORTED_OBJECTS_Release
        IMPORTED_SONAME
        IMPORTED_SONAME_Debug
        IMPORTED_SONAME_Release
        IMPORT_PREFIX
        IMPORT_SUFFIX
        INCLUDE_DIRECTORIES
        INSTALL_NAME_DIR
        INSTALL_REMOVE_ENVIRONMENT_RPATH
        INSTALL_RPATH
        INSTALL_RPATH_USE_LINK_PATH
        INTERFACE_AUTOUIC_OPTIONS
        INTERFACE_COMPILE_DEFINITIONS
        INTERFACE_COMPILE_FEATURES
        INTERFACE_COMPILE_OPTIONS
        INTERFACE_INCLUDE_DIRECTORIES
        INTERFACE_LINK_DEPENDS
        INTERFACE_LINK_DIRECTORIES
        INTERFACE_LINK_LIBRARIES
        INTERFACE_LINK_OPTIONS
        INTERFACE_POSITION_INDEPENDENT_CODE
        INTERFACE_PRECOMPILE_HEADERS
        INTERFACE_SOURCES
        INTERFACE_SYSTEM_INCLUDE_DIRECTORIES
        LIBRARY_OUTPUT_DIRECTORY
        LIBRARY_OUTPUT_DIRECTORY_Debug
        LIBRARY_OUTPUT_DIRECTORY_Release
        LIBRARY_OUTPUT_NAME
        LIBRARY_OUTPUT_NAME_Debug
        LIBRARY_OUTPUT_NAME_Release
        LINK_DEPENDS
        LINK_DEPENDS_NO_SHARED
        LINK_DIRECTORIES
        LINK_FLAGS
        LINK_FLAGS_Debug
        LINK_FLAGS_Release
        LINK_INTERFACE_LIBRARIES
        LINK_INTERFACE_LIBRARIES_Debug
        LINK_INTERFACE_LIBRARIES_Release
        LINK_INTERFACE_MULTIPLICITY
        LINK_INTERFACE_MULTIPLICITY_Debug
        LINK_INTERFACE_MULTIPLICITY_Release
        LINK_LIBRARIES
        LINK_OPTIONS
        LOCATION
        LOCATION_Debug
        LOCATION_Release
        MANUALLY_ADDED_DEPENDENCIES
        MSVC_RUNTIME_LIBRARY
        NAME
        NO_SONAME
        NO_SYSTEM_FROM_IMPORTED
        OUTPUT_NAME
        OUTPUT_NAME_Debug
        OUTPUT_NAME_Release
        PCH_WARN_INVALID
        PCH_INSTANTIATE_TEMPLATES
        PDB_NAME
        PDB_NAME_Debug
        PDB_NAME_Release
        PDB_OUTPUT_DIRECTORY
        PDB_OUTPUT_DIRECTORY_Debug
        PDB_OUTPUT_DIRECTORY_Release
        PRECOMPILE_HEADERS
        PRECOMPILE_HEADERS_REUSE_FROM
        PREFIX
        PRIVATE_HEADER
        PUBLIC_HEADER
        RESOURCE
        RUNTIME_OUTPUT_DIRECTORY
        RUNTIME_OUTPUT_DIRECTORY_Debug
        RUNTIME_OUTPUT_DIRECTORY_Release
        RUNTIME_OUTPUT_NAME
        RUNTIME_OUTPUT_NAME_Debug
        RUNTIME_OUTPUT_NAME_Release
        SOURCE_DIR
        SOURCES
        STATIC_LIBRARY_FLAGS
        STATIC_LIBRARY_FLAGS_Debug
        STATIC_LIBRARY_FLAGS_Release
        STATIC_LIBRARY_OPTIONS
        SUFFIX
        TYPE
        VERSION
)

Take Protobuf for example.

  • The protobuf::libprotoc declared by Official Config Files is SHARED IMPORTED.
  • The protobuf::libprotoc declared by CMakeDeps is INTERFACE IMPORTED.

Screeshots:

image image

@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” Libraries
  • SHARED IMPORTED for “Shared” Libraries

If 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 as INTERFACE 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 resolve TARGET_RUNTIME_DLLS. So in this case, I don’t think the issue has to do with Qt6::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 are SHARED. We will investigate this!