[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

Brad King wrote:

> On 12/02/2012 04:35 AM, Stephen Kelly wrote:
> 
>> 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 added these three commits to the topic:
> 
>  3a1660d GenEx: Clarify $<CONFIG_DEBUG> documentation
>  977a098 Cleanup INTERFACE_LINK_LIBRARIES property implementation
>  93ac463 Fix typo in CMP0019 documentation
> 
> and then rewrote it to squash things together and update the commit
> messages.

Thanks.

> 
>> I'm not sure about DEBUG_CONFIG either. I think I'd prefer a more generic
>> solution like $<COMPATIBLE_CONFIG:cfg>
> 
> The CONFIG_DEBUG property complements the "debug" keyword in tll().
> That's all it does, and it exactly matches the behavior we need in
> the motivating case.  Something like $<COMPATIBLE_CONFIG:cfg> may
> be useful but that can be added in the future in another topic.

Yes, it could be added in the future, but the generator expression added by 
generatorIface could not then be ported to use it (after a release is made 
with this patch in it) without breaking behavior backward compatibility.

> 
>> 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.
> 
> Don't worry about the weekly review session schedule for this topic.
> We're actively interacting on it and I'll merge it to master as soon
> as it's ready.

Ok, thanks.

> 
>> How can we best prevent scope-creep in topics?
> 
> This isn't scope creep.  This is the minimum needed to correctly
> introduce the policy.
> 
>> 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?
> 
> When constructing a topic pretend that each commit is the last commit
> you will ever make to CMake, without the rest of the topic after it,
> or at least without future topics.  If it doesn't make sense to leave
> it off at that point then the commits are organized incorrectly and
> therefore harder to review.

That would mean that add-INTERFACE_LINK_LIBRARIES-property should also 
include the rest of the commits to add the LINK_LIBRARIES property and use 
that for static libraries to generate the INTERFACE_LINK_LIBRARIES property 
on exported targets. Otherwise add-INTERFACE_LINK_LIBRARIES-property topic 
would be introducing a bug.

Does all of this need to be in one large topic, or is the above bug 
acceptible anyway?

Thanks,

Steve.