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. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
