[cmake-developers] INTERFACE_LIBRARY target type

Brad King brad.king at kitware.com
Tue Sep 10 10:24:25 EDT 2013


On 08/28/2013 11:31 AM, Stephen Kelly wrote:
> 1) We already have ALIAS targets, which leaves INTERFACE_LIBRARY to cover 
> the uses cases of

Okay.

> 2) In my branch, the 'old' (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)? 
> are always ignored for INTERFACE_LIBRARY types, for simplicity like the 
> above, and always being able to rely on the INTERFACE_LINK_LIBRARIES 
> property for them.

Good.

> 3) I have left a TODO note in cmLocalGenerator.cxx about the return value 
> from GetRealDependency.

Callers of GetRealDependency are looking for a file-level dependency.
Targets like OBJECT_LIBRARY and INTERFACE_LIBRARY have no real file
on which to depend.  The OBJECT_LIBRARY comment "This was listed to
get the target-level dependency" is talking about ordering dependencies
among logical targets.

> 4) The target_* commands always need to be invoked with an explicit 
> INTERFACE option.

In other words, with their existing INTERFACE option because PUBLIC
and PRIVATE both affect the compilation and linking of the target
itself which makes no sense for INTERFACE_LIBRARY.  Good.

> 5) The INTERFACE_LIBRARY can be installed and exported, resulting in 
>  
>  add_library(Foo::iface INTERFACE IMPORTED)
>  # ...
> 
> In my branch, the versions are a bit messed up in the install(EXPORT) code, 
> due to what's currently in master. That will be cleaned later.

Okay.

> 6) When we get transitive INTERFACE_SOURCES, it will be possible to 'link 
> to' OBJECT_LIBRARYs:
[snip]
> So, it might make sense to revisit whether it is allowed to link to 
> OBJECT_LIBRARYs. Either way, the obj_iface can't be exported in this case, 
> because the dependent obj library can't be exported.

We don't allow linking to object libraries just for simplicity in their
original introduction.  We need to define behavior when they are reached
transitively.  Let's leave this aside for now and come back to it later.

> 7) I've only implemented the support for this target type in the Makefile 
> generator so far. I can also do the Ninja one after all of the details about 
> how it works are sorted out.
> 
> Can someone else implement the VS and Xcode support? I'm too unfamiliar with 
> those generators.

Do you mean support for "make iface" in the other generators?

> 8) I made it possible to use 
> 
>  make iface
> 
> to build the *dependencies* of iface. The special /requires /depends and 
> /build sub-targets are not generated for INTERFACE_LIBRARY targets.

Okay.  Yes, all those requires/etc. steps are for building files in the
target itself.

> 9) INTERFACE_LIBRARY targets are always effectively EXCLUDE_FROM_ALL because 
> they have no direct outputs.

...but they do have dependencies on other targets, as built by "make iface".
If a given directory contains nothing but an interface target that depends
on real targets from other directories, shouldn't typing "make" in that
directory bring everything up to date to use the interface?

-Brad



More information about the cmake-developers mailing list