[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

Brad King wrote:
> And another.  Here is new documentation I've written based on this
> discussion.

Done now.

I would really prefer if you would commit this directly to the branch 
instead, as you had written it locally already. There is no point in having 
to go through me. The branch can be our collaboration point. Me copying your 
patch and pushing it myself feels like needless busy-work.

Simliarly with the link-type keywords in the INTERFACE_LINK_LIBRARIES 
property check, you might not like the message string that I used in the 
error, you might ask me to change it, etc and we'll end up doing more trips 
through me, more latency. Please feel free to update it directly if that is 
the case.

I'm not sure about DEBUG_CONFIG either. I think I'd prefer a more generic 
solution like $<COMPATIBLE_CONFIG:cfg> which would account for 
MAP_IMPORTED_CONFIG_<CONFIG> too. It's something worth discussing at least, 
and the discussion could go on past next Tuesday. 

If we do discuss it and insist that it's a solved-problem before add-
INTERFACE_LINK_LIBRARIES-property can be merged, that would mean that the 
entire add-INTERFACE_LINK_LIBRARIES-property topic would not get merged to 
master for another week. I have at least 7 topics depending on that one 
being in master. I don't think the $<CONFIG:Debug> is so important that it 
should block that. It's a minor limitation which could equally be addressed 
after add-INTERFACE_LINK_LIBRARIES-property is in, in parallel with all the 
other stuff which depends on that.

How can we best prevent scope-creep in topics?

A few weeks ago I didn't have all the export-related stuff for 
INTERFACE_LINK_LIBRARIES in the same commit that introduced it, but I had 
follow-up commits in a follow-up topic to handle export() and 
install(EXPORT) for it. 

That would have simplified the commit that actually added 
INTERFACE_LINK_LIBRARIES I think, and I would still have been able to add 
most of my follow-up topics once it was in. You would have probably noticed 
that it was missing (exactly as you did with the context-target stuff and 
the static library conversion of link implementation into link interface in 
exports), and it might be harder for you to keep track of and review. Do you 
have any preference?

If I have patches or features which other pending topics depend on, should I 
try to get a partial-implementation of limited scope in first and point to 
the other topics in gitorious, or does that not work for you?

As a side-note, I'm no longer aiming to get the INTERFACE_LIBRARY type into 
2.8.11 due to time constraints and incomplete implementation. It will have 
to wait until 2.8.12.

> Please update the topic to implement the tll() behavior
> with respect to the policy and LINK_PUBLIC.

I pushed that to no-export-old-link-interface branch in my gitorious clone a 
few days ago. I guess I should have pointed it out, but I didn't realize it 
was a blocker for add-INTERFACE_LINK_LIBRARIES-property to get in. It also 
might open up new questions about documentation and implementation, and 
might introduce new failures in the dashboard. I'd prefer to discuss and 
merge it separately after add-INTERFACE_LINK_LIBRARIES-property is in. 
Otherwise add-INTERFACE_LINK_LIBRARIES-property will never get in.

If you disagree, please cherry-pick it to the add-INTERFACE_LINK_LIBRARIES-
property branch and merge it to next yourself so that we can move forward 
with other things.

Thanks,

Steve.