[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

Stephen Kelly steveire at gmail.com
Fri Nov 30 09:31:17 EST 2012


Brad King wrote:

> On 11/30/2012 08:39 AM, Brad King wrote:
>> On 11/29/2012 04:35 PM, Stephen Kelly wrote:
>>> I've pushed add-INTERFACE_LINK_LIBRARIES-property to my gitorious clone.
>> 
>> I'll look at this one now.
> 
> This still appears to use the policy in ComputeImportInfo.
> In our current design CMake >= 2.8.11 should always use the
> new interface if it is available.  There is no need to check
> the policy at all there.  In fact the policy should not apply
> to imported targets at all.  It's only the value when a target
> is originally created that matters in determining which of the
> two interfaces it exposes to consumers.

Ok. I was confused by the sentence 

 'Therefore when the policy is not set to NEW we need to pretend that
  the new interface is not defined.'

in your previous mail.

I think I now understand what you mean though.

> 
> In ComputeLinkInterface it appears you store newInterfaceLibs
> in iface.Libraries after evaluating generator expressions with
> the target as its own context (and similarly in ComputeImportInfo).
> IIRC we planned to expose the generator expressions in the link
> interface so they would be ultimately evaluated in the context of
> the consuming target.

Yes, I put that in a separate patch, because it has its own complexity and I 
wanted to add its own tests. In my gitorious clone it is currently 
0e7a0d6602c467a2ccc938f9313578edcf6b8145 'Use a context-target when 
evaluating generator expressions.' The unit tests in the topic depend on 
earlier commits. Is it ok to push it later when the dependencies are in? 
Having multiple dependent branches in next is a pain when an early branch 
needs to be updated. It makes merging to next a lot more work.

Thanks,

Steve.





More information about the cmake-developers mailing list