conan
conan copied to clipboard
conan-io
[question] Why does the CMake generator define INTERFACE IMPORTED targets rather than only IMPORTED?
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.
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.
@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.
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)
@memsharded @lasote @czoido Is it something you have taken into account in conan v2?
I think, at least in theory 😅 , we will have that information thanks to the proposed package types https://github.com/conan-io/tribe/pull/27 and requirements traits https://github.com/conan-io/tribe/pull/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.
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 :'(
This PR https://github.com/conan-io/conan/pull/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.
