[cmake-developers] INTERFACE_LINK_LIBRARIES property?

[Brad King]

On 05/30/2013 10:50 AM, Stephen Kelly wrote:
> I'm not convinced that a policy to disallow the old and new signatures 
> together is actually better though. It preserves the historical behavior 
> even if the policy is NEW, and will be a bit confusing for anyone attempting 
> to use a new signature with a LHS target, especially if the new signature is 
> already in use elsewhere in the project or file ('It works with foo, why 
> doesn't it work with bar in the same file?!?').

* The error (or warning when policy is not set) message should list all
  call sites along with which signature they use and explain that they
  need to be made consistent.  Currently the tll() docs for the old
  signature warn that the new signature can "break" the public interface.

* The signature policy setting should be queried at each call site rather
  than recorded when the target is created.

> For anyone hitting issues like those, it will make sense at that point to 
> port everything to the new signature anyway for maintenance

Yes, and the signature policy's message can help with doing that.

> In spite of the above, I can agree to that in the interest of moving along 
> and getting some new consistent signatures in place.

That is my goal also.  My "signature policy" proposal is motivated by:

(1) The old signatures make sense on their own.
    Lots of projects use them.  They are not "wrong".

(2) The new signatures make sense on their own.
    They have better shared library interface defaults.

(3) Combinations of old and new signatures produce confusing results

Policies are intended for use when a new behavior is clearly superior
to the old behavior.  Both (1) and (2) are fine individually, even with
INTERFACE_LINK_LIBRARIES.  It is the behavior in (3) that is bad and
making old/new signatures exclusive is clearly superior.

>> I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
>> for application of usage requirements.  The requirement to link
>> dependents to a static library's dependencies is an implementation
>> detail for linking only.
> 
> Something like this will probably be possible. I'll have a closer look at 
> the implementation later.

Great, thanks.

-Brad