[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Brad King]

On 11/30/2012 10:10 AM, Stephen Kelly wrote:
> Brad King wrote:
>> You could add one commit at the end of each of those to revert them
>> from next until we've worked out this part.  Then go back and rebase
>> them on the result.
> 
> I tried doing that, but they're all hopelessly tangled. Do you think you can 
> help?

I'll revert the entire block of topics for you.  After that you can
start from scratch by rebasing the INTERFACE_LINK_LIBRARIES changes
by themselves on master.  I'll respond again when it's ready.

> Are there other things we need to sort out with the add-
> INTERFACE_LINK_LIBRARIES-property branch?

Probably, but once we start it over with no dependents then it will
be easy to revise.

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

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?

-Brad