[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

Brad King wrote:
>> Does the static library stuff need
>> to be accounted for in some way already in that branch?
> 
> Well, we want generator expressions in tll() to work for static
> libraries.  Therefore we must populate INTERFACE_LINK_LIBRARIES
> for IMPORTED targets generated from static libraries.  However,
> in the producing (exporting) project it does not make sense to
> have separate LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES for
> static libraries.  The property must remain undefined for static
> libraries just as LINK_INTERFACE_LIBRARIES is now.
> 
> Somehow the "link implementation" must be turned into
> IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> and/or the new
> INTERFACE_LINK_LIBRARIES when exporting targets.  That must be
> built into ComputeLinkInterface if it is not already.  Again I'm
> not sure how to know when to not export the old interface.  In
> this case it is never set explicitly by the user.  Perhaps it can
> depend on whether the link implementation requires any generator
> expressions besides $<CONFIG:>.  Such expressions would not be
> representable in the old interface anyway.

I think I'd prefer an option to export() and install(EXPORT) to not export 
the old link interface, but I'll look into it a bit later.

> 
> IIRC you were planning to move tll()'s storage from C++ structures
> to a LINK_LIBRARIES property that supports generator expressions.
> Is that still the case?

Yes. That's what the link-libraries-generator-expression topic is about, 
particularly b4ab0c15bc19a85f3f6f8f6b5cadb33b287ae403 'Add 
cmTarget::GetDirectLinkDependencies.'.

It is not possible to completely remove the old stuff because of backward 
compatibility concerns (CMP0003 - this is what 
d5cf644ac2e3f035d2d3413dd98aa0d46f9f27eb was about).

Thanks,

Steve.