[cmake-developers] INTERFACE_LIBRARY target type

[Stephen Kelly]

Brad King wrote:

>> Having said that, would IMPORTED targets actually be good enough for all
>> the things you list, maybe with some wrapper macros ?
> 
> The IMPORTED targets still need to have an IMPORTED_LOCATION that refers
> to a real file, so they are not quite equivalent to the proposed INTERFACE
> or ALIAS targets.  What they all share in common is the lack of build-time
> actions.

Actually it might be useful to make it possible to do this:

 add_library(foo SHARED foo.cpp)
 add_library(bar SHARED bar.cpp)
 add_library(iface INTERFACE)
 target_link_libraries(iface INTERFACE foo bar)

and have

 make iface 

cause a (re)build of foo and bar if necessary. This would be in conflict 
with the idea of considering targets with double colons to be imported 
targets if the INTERFACE_LIBRARY was used in the alias pattern I described 
before.

Perhaps we could do aliasing with a target property instead?

 add_library(foo SHARED foo.cpp)
 set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo)

?
 
Just another angle to consider in the design of this stuff.

> The proposed INTERFACE and ALIAS target types would remain the same when
> exported instead of being converted to IMPORTED targets.  However, all
> their interface content would be mapped to the exported names.
> 
> I think new target types are worth considering for these roles to keep the
> "IMPORTED" concept focused on importing targets with files on disk.

This might need some deeper consideration. I like that IMPORTED targets can 
not be re-exported, and I would expect the same for the INTERFACE_LIBRARY 
type.

IMPORTED targets also have a different scope to non-imported targets. I'd 
expect that if I find_package somewhere and a KF5::iface INTERFACE_LIBRARY 
results, that follows the same scope rules as KF5::KArchive.

The code would become uglier too. We'd need to add special cases for 
INTERFACE_LIBRARY types in places where we currently check IsImported, eg 
cmTarget::AddLinkLibrary.

Also, commands like target_include_directories() shouldn't work with 
IMPORTED targets as the first argument, but if such targets are not marked 
as IMPORTED, there would be no way to enforce that. Some configuration-
relevant information is only known to the exporting project upstream. See 
commit b98d14d40016efee420bee26b9795880fdf6a5f8 (Disallow porcelain to 
populate includes and defines of IMPORTED targets., 2013-01-21).

Thanks,

Steve