On 11/07/2012 09:33 AM, Stephen Kelly wrote:
> Ok. 

Thanks for the full example.

> Additionally, the order of the elements in INTERFACE_LINK_LIBRARIES is the 
> same as the order in IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG (as added by 
> tll()) **.

Okay.

> If downstream uses 2.8.10, the effect is the 
> IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG property is read as before.

Good.

> However, I can see that if upstream instead did this:
> 
>  set_property(TARGET foo APPEND PROPERTY 
>      LINK_INTERFACE_LIBRARIES_DEBUG yip)
>  target_link_libraries(foo LINK_PUBLIC bang floom)
> 
> Then 2.8.10 would result in 'yip;bang;floom', but 2.8.11 would result in 
> 'bang;floom;yip'. I guess that's the case you're interested in. 

Yes, plus possibly others we haven't thought of from trying to do a
"union" of old and new interfaces.

> In my topic it uses the result of processing INTERFACE_LINK_LIBRARIES, then 
> whatever is in LINK_INTERFACE_LIBRARIES_DEBUG but not in the result yet.

This will not be reliably compatible given cases like the above.
This is why we need to use either one interface or the other, always.
If the consumer builds with 2.8.11 but we somehow know to ignore the
new interface and behave like 2.8.10 then it will all work.

Perhaps this is where the policy should go.  If the policy is set to
OLD, use only the old interface.  If the policy is set to NEW then
use only the new interface.  Otherwise compute the link rules twice,
once using just the old interface and once using just the new
interface.  If they are the same, use the result.  If they are not
the same, then issue the policy warning and use old behavior.

In the long term projects will eventually set cmake_minimum_required
to >= 2.8.11 and the policy will always be NEW.  However, how do we
eventually stop adding the old interfaces to the export files?

-Brad
--

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

Reply via email to