Brad King wrote: > 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.
What kind of complexity? Complexity of implementation, or complexity for users (having to understand that using tll() with targets means not needing include_directories() after the patch)? Alex's concern is the latter only afaik. I still think that introducing a new command is more complex for all users. Davids concern appears to be the former, but I think I've shown that that is not related to the new-command-versus-overload-tll question. > 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. Yes, I agree. > If possible we should not ask everyone to pay a cost for these features > if they do not want to use them. Yes, I agree. > 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) True. > >> 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. Yes, that's what I means by policy with the same foo. But I guess as it's a new command, no policy would be needed. I do think that proposal makes the whole thing harder to use, and makes the user need to understand a lot more about what's going on under the hood. > 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. True. > > I like Daniel's name "target_use_interfaces" for the new command rather > than "target_use_targets". The RHS might not always be targets. Alex's proposal was that it would only accept targets, not library paths. What else do you think would be in the RHS apart from targets? I don't like the target_use_interfaces name because it conflicts with the INTERFACE_LIBRARY type. The name implies that it can only be used with targets of that type. Anyway, let's discuss the actual name of any new command later. For now, can we agree that the only reason to use a new command or not depends on complexity for the user? Then can someone (preferably not me) please make a list of the types of users who will be affected by either choice (and in what situations) and we can discuss that? Eg, I don't believe most developers of KDE applications will be affected - in practice they ignore the buildsystem and it is Alex or, more likely, me who will port them to KDE Frameworks 5 on a buildsystem level at least. Any power users of CMake will learn about any new tll behavior from the release notes, and non-power users probably won't notice until the notice by accident. New users can follow the documentation or the example of KDE or others. 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
