[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.

[lasote]

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.

[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.