On 12/07/2012 06:10 AM, Stephen Kelly wrote: > Stephen Kelly wrote: >> I haven't tried to analyse how much of the complexity is due to whether >> target_use_targets or target_link_libraries is used. I think the harder >> parts of this topic so far have been related to exports. > > I've split out the part of the commit that changes tll(), and I think the > complexity remains in the part that would be essential even with a new > command.
Obviously there will be complexity inherent to the new capabilities. I think the goal of this discussion is to re-design the interface that enables the new features in order to avoid complexity related to backward compatibility. Many of my concerns raised in the other threads relate to how existing projects will be affected. Ideally existing projects should continue to work unmodified, even without a policy if possible. If possible we should not ask everyone to pay a cost for these features if they do not want to use them. I think we can find a new way to specify interfaces and activate the new features that looks natural for new code but does not overlap with existing use cases. This should address Alex's and David's concerns and make it easier to review and accept. For reference, existing proposals are summarized here: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements > target_link_libraries(foo bar) > target_use_targets(foo bing) > > bar will no longer be in the link interface when exported. That is also currently true for target_link_libraries(foo bar) target_link_libraries(foo LINK_INTERFACE_LIBRARIES bing) > Even if we have a policy for when people use the old and new command with > the same foo, people will use both tll() and the new command in the same > project (with different targets), and that will be confusing for them. Another idea is to simply not allow both commands to be used on a given target. Since the new command does not yet exist this cannot break any existing projects. One must either specify everything by the new command or everything by the old command. We could also use this to switch the default link interface to be empty for shared library targets. If a newly created target doesn't link to anything then of course its link interface is empty too. Once one uses the new command to link to something then since it is a new command we can make the link interface empty without changing existing projects. I like Daniel's name "target_use_interfaces" for the new command rather than "target_use_targets". The RHS might not always be targets. -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
