[question] Why does the CMake generator define INTERFACE IMPORTED targets rather than only IMPORTED?

[GordonJess]

My understanding is that INTERFACE targets are for when an actual library file does not exist on disc and you just want to group together and add a logical set of flags, sources, headers etc. in the compile/link process of another target.

However, in some cases the dependencies resolved through Conan do have an actual library file. And in these cases I might like to know where this library file is stored on disc (in my particular use case I want to extract symbols from it). For IMPORTED targets I would normally use something like the IMPORTED_LOCATION property or the $<TARGET_FILE:tgt> generator expression, but this is not possible for INTERFACE targets which only support "whitelisted" INTEFRACE_ properties.

Maybe there a reason for this I'm not aware of. If so, can you suggest any other way I might be able to get the location of these INTERFACE IMPORTED library files? If not, I'd like to propose that dependencies which have a library are defined as IMPORTED only.

[SpaceIm]

A CMake imported target must have a type (STATIC, SHARED, INTERFACE or UNKNOWN): https://cmake.org/cmake/help/latest/command/add_library.html#imported-libraries
Maybe conan should first provide a mechanism in package_info() to indicate if a specific lib file is shared or static, then generators could use this information to create proper imported targets.

[GordonJess]

@SpaceIm, until such a mechanism exists, isn't the target type UNKNOWN, not INTERFACE? So perhaps conan could create them as such by default - this would at least give the option of using the other target properties.

[schletti2000]

I also would like to see that the conan_find_package_multi generator creates an IMPORTED target rather than IMPORTED INTERFACE. This would enable awesome things like the new CMake $<TARGET_RUNTIME_DLLS:tgt> generator expression. Lets take zmq for example, we have to fall back to using the zmq provided find_package(Zero_MQ) just to get the LOCATION of the dll in the dependency tree. This may be better anyway since we may use zmq provided macros, but if the generated find_package files from conan would provide the (?:IMPORTED_)LOCATION of the dll then we could use this to INSTALL/POST_BUILD copy_if_different of all dependencies. Currently we use conan deploy just to get the dlls (spawning venv included).
EDIT: I just remembered that the conan find_packages do provide an IMPORTED_LOCATION, just that it's set to the .lib. I assume this is because the target is an INTERFACE target. So the question would be if its possible to generate a library which is just IMPORTED.

Perhaps helpful: CMake Wiki - Importing an exporting targets

add_library(bar SHARED IMPORTED)
set_property(TARGET bar PROPERTY IMPORTED_LOCATION c:/path/to/bar.dll)
set_property(TARGET bar PROPERTY IMPORTED_IMPLIB c:/path/to/bar.lib)

[SpaceIm]

@memsharded @lasote @czoido Is it something you have taken into account in conan v2?

[lasote]

I think, at least in theory 😅 , we will have that information thanks to the proposed package types conan-io/tribe#27 and requirements traits conan-io/tribe#26 so the generators could be improved. I don't know if changing the targets that way could have other unexpected results but we should try, so I'm assigning the "look into" tag and milestone to take a look.

[ILoveGoulash]

Friendly ping.

[traversebitree]

Ping again.

[LarrxX]

pinging too :)
I just encountered the same problem: I have no way of getting the DLL files to copy next to my target using pure CMake and the conan generators (made with conan 2.1's full_deploy) because of this :'(

[memsharded]

This PR #15914 is creating the var CONAN_RUNTIME_LIB_DIRS, which allows to implement the install(RUNTIME_DEPENDENCY_SET my_app_deps which seems to be the CMake recommended way to gather shared libraries from dependencies.