On 11/06/2012 02:07 PM, Stephen Kelly wrote: > Brad King wrote: >> How do you propose to trigger this policy warning? > > True, I don't know how to warn about it. Does that mean that a policy is > entirely unsuitable?
It may still be suitable, just hard to implement. The handling of the old property names discussed below may influence how we have to activate the new behavior anyway. >> I don't think we should honor both properties at once. If the new >> name is set the old names should be ignored (perhaps with a warning if >> an old name is set too). > > That could be an option. I think it gets complicated though. > > 1. In my branch I made tll() populate the INTERFACE_LINK_LIBRARIES prop That opens a big can of worms because now activation of new interfaces for these features does not depend on modification of projects using the old interfaces. An export generated with the new interfaces in it will not be understood by an older CMake. This is okay if activation of new interfaces is explicit and intentional. The user has then declared they are willing to require 2.8.11 for downstream consumers. If activation is implicit then the generated export files must be able to work with either older or newer CMakes. I think 2.8.11 will have to generate export files that provide both old and new interfaces. The choice will be made when they are loaded and depends on whether the application has also activated support for the new interfaces. The question remains how to make activation explicit when combinations of old and new CMake versions are involved but automatic when everyone requires a newer CMake. >> Yes, interfaces should be flattened and replaced with their content. > > So the INTERFACE_LINK_LIBRARIES property would be handled differently for an > INTERFACE_LIBRARY than a SHARED_LIBRARY. I think that's a bit confusing. An interface wrapping around a single other library should be equivalent to defining the interface directly on that other library. The logical name of the interface target is kind of like a generator expression when referenced in INTERFACE_LINK_LIBRARIES. Wherever it is you process the generator expressions, first transform "myinterface" to $<TARGET_PROPERTY:myinterface,INTERFACE_LINK_LIBRARIES> or something like that. > What I'm proposing is removal of an existing optimization, but ok I'll go > ahead and do that. I meant the "optimize later" as general advice. Just remove the current optimization because it is in the way of correctness of your change. Only if future profiling shows that the optimization is worthwhile should it be restored. -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
