Hi Steve, After our "Setting include directories via target_link_libraries" thread discussion has decided to stick with the individual properties I've thought a bit more about how to transition the link interface properties. I think the following will be a cleaner way to do the new link interface properties and the transition policy.
First I'll define how the properties behave when building a target. I'll cover exporting below. In the OLD behavior the link interface is completely determined as it is in CMake 2.8.10 by the LINK_INTERFACE_LIBRARIES(_<CONFIG>) properties. The target_link_libraries command will populate the properties as it does now and leave the new names untouched. In the NEW behavior the link interface is completely determined by the new INTERFACE_LINK_LIBRARIES property. All forms of tll() including its LINK_INTERFACE_LIBRARIES mode will populate only the new properties. The old property is completely ignored. When the property is not set (internally it is WARN) then tll() will populate both the old and new properties. ComputeLinkInfo will compute both the old and new style link interfaces, warn if they are different, and use the old one. The new target_use_interfaces command will be allowed only on targets created with the policy set to NEW. This will be natural because projects will need cmake_minimum_required(VERSION xxx) to use the new command anyway, and that will set the policy to NEW. The new command will only populate the new properties. A single invocation of it on a target will be enough to make the default link interface empty for shared libraries. For STATIC libraries the target_use_interfaces command PRIVATE/INTERFACE keywords still make sense because there could be different -I/-D for the implementation versus the interface. Only linking must be PUBLIC always. For STATIC libraries we can define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for linking and that it always populates both LINK_LIBRARIES LINK_INTERFACE_LIBRARIES. Note that for STATIC libraries the LINK_LIBRARIES property will not be used for anything except build-order dependencies. Unlike the old LINK_INTERFACE_LIBRARIES the new INTERFACE_LINK_LIBRARIES will be used for static libs too. That way projects can deal with the link interface for all targets in the same way. Now, on to exporting. Unlike the previous iteration the policy affects it too. When the policy is OLD/WARN we export only the old interface and not the new interface. When the policy is NEW we export only the new interface and not the old interface by default. We can have a new property to explicitly request that the old link interface properties be exported. We can either ask projects to set the old interface properties manually for export or try to compute the values from the new ones by pre-evaluating the generator expressions for each configuration. This will allow projects to support older CMake versions for their clients if they want to, but it will be an explicit decision. Note that your generator expression evaluation in imported targets will still need to handle MAP_IMPORTED_CONFIG_<CONFIG> correctly. -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
