<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 12, 2012 at 4:16 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:neundorf@kde.org" target="_blank">neundorf@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Tuesday 11 December 2012, Stephen Kelly wrote:<br>
> Brad King wrote:<br>
> > On 12/07/2012 06:10 AM, Stephen Kelly wrote:<br>
> >> Stephen Kelly wrote:<br>
> >>> I haven't tried to analyse how much of the complexity is due to whether<br>
> >>> target_use_targets or target_link_libraries is used. I think the harder<br>
> >>> parts of this topic so far have been related to exports.<br>
> >><br>
> >> I've split out the part of the commit that changes tll(), and I think<br>
> >> the complexity remains in the part that would be essential even with a<br>
> >> new command.<br>
> ><br>
> > Obviously there will be complexity inherent to the new capabilities.<br>
> > I think the goal of this discussion is to re-design the interface that<br>
> > enables the new features in order to avoid complexity related to backward<br>
> > compatibility.<br>
><br>
> What kind of complexity?<br>
><br>
> Complexity of implementation, or complexity for users (having to understand<br>
> that using tll() with targets means not needing include_directories() after<br>
> the patch)?<br>
><br>
> Alex's concern is the latter only afaik.<br>
<br>
</div>Yes, I was looking at this only from a users perspective so far.<br>
<div class="im"><br>
> I still think that introducing a<br>
> new command is more complex for all users.<br>
<br>
</div>Here we disagree.<br>
<br>
If these are separate commands, both examples below can be valid cmake code<br>
for the same installation of package Foo:<br>
<br>
find_package(Foo REQUIRED)<br>
<br>
include_directories(${Foo_INCLUDE_DIRS})<br>
<div class="im"><br>
add_executable(hello main.cpp)<br>
<br>
target_link_libraries(hello ${Foo_LIBRARIES})<br>
<br>
</div>-----------------------------<br>
as well as<br>
<br>
find_package(Foo REQUIRED)<br>
<br>
add_executable(hello main.cpp)<br>
<br>
target_use_targets(hello TARGETS Foo:FooLib)<br>
<br>
<br>
IMO it is a good thing that this way a package can support both the old and<br>
the new way at the same time, and that using a package the new way is very<br>
obvious from just looking at the cmake code.<br>
A similar effect can be achieved by adding a keyword to tll(), e.g.<br>
<br>
target_link_libraries(hello ${JPEG_LIBRARIES} USE_INTERFACES Foo:FooLib)<br>
<br>
This would have the same effect, but people could simply hide the<br>
USE_INTERFACES keyword in a variable:<br>
set(Foo_LIBRARIES USE_INTERFACES Foo::FooLib)<br>
<br>
and then it's again hidden:<br>
target_link_libraries(hello ${JPEG_LIBRARIES} ${Foo_LIBRARIES})<br>
<br>
...<br>
<div class="im">> >> Even if we have a policy for when people use the old and new command<br>
> >> with the same foo, people will use both tll() and the new command in<br>
> >> the same project (with different targets), and that will be confusing<br>
> >> for them.<br>
<br>
</div>Why will this be confusing ?<br>
Those two commands will have clear and separate functionality.<br>
tll() links, the new one links, sets include dirs and defines using target<br>
propertiesm and it can error/warn if something else that a target with all<br>
necessary properties is used there.<br>
<div><div class="h5"><br>
> > Another idea is to simply not allow both commands to be used on a given<br>
> > target.<br>
><br>
> Yes, that's what I means by policy with the same foo. But I guess as it's a<br>
> new command, no policy would be needed.<br>
><br>
> I do think that proposal makes the whole thing harder to use, and makes the<br>
> user need to understand a lot more about what's going on under the hood.<br>
><br>
> > Since the new command does not yet exist this cannot break any<br>
> > existing projects.  One must either specify everything by the new command<br>
> > or everything by the old command.<br>
> ><br>
> > We could also use this to switch the default link interface to be empty<br>
> > for shared library targets.  If a newly created target doesn't link to<br>
> > anything then of course its link interface is empty too.  Once one uses<br>
> > the new command to link to something then since it is a new command we<br>
> > can make the link interface empty without changing existing projects.<br>
><br>
> True.<br>
><br>
> > I like Daniel's name "target_use_interfaces" for the new command rather<br>
> > than "target_use_targets".  The RHS might not always be targets.<br>
><br>
> Alex's proposal was that it would only accept targets, not library paths.<br>
> What else do you think would be in the RHS apart from targets?<br>
<br>
<br>
> I don't like the target_use_interfaces name because it conflicts with the<br>
> INTERFACE_LIBRARY type. The name implies that it can only be used with<br>
> targets of that type.<br>
><br>
> Anyway, let's discuss the actual name of any new command later.<br>
><br>
> For now, can we agree that the only reason to use a new command or not<br>
> depends on complexity for the user?<br>
><br>
> Then can someone (preferably not me) please make a list of the types of<br>
> users who will be affected by either choice (and in what situations) and we<br>
> can discuss that?<br>
><br>
> Eg, I don't believe most developers of KDE applications will be affected -<br>
> in practice they ignore the buildsystem<br>
<br>
</div></div>I prefer obviousness over convenience.<br>
While this may lead to more code, it makes the code easier to understand and<br>
easier to debug, and hopefully less likely to be considered as "magic" and<br>
thus be ignored. ;-)<br>
<div class="im"><br>
> and it is Alex or, more likely, me<br>
> who will port them to KDE Frameworks 5 on a buildsystem level at least. Any<br>
> power users of CMake will learn about any new tll behavior from the release<br>
> notes, and non-power users probably won't notice until the notice by<br>
> accident. New users can follow the documentation or the example of KDE or<br>
> others.<br>
<br>
</div>All kinds of users will notice when for whatever reason something suddenly<br>
doesn't build for them due to bad include dirs.<br>
When they then see<br>
<br>
target_link_libraries(hello ${Foo_LIBRARIES} ${Bar_LIBRARIES})<br>
<br>
there is no hint that this does more than it always did, so why should they<br>
even check the documentation whether tll() now also sets include dirs ?<br>
They will just see that their include dirs are wrong in some way, but figuring<br>
out that this might be caused by target properties hidden in ${Foo_LIBRARIES}<br>
will probably need an advanced user who knows about this new feature.<br>
<br>
This goes away if a new command is used.<br>
<br>
Probably it would be good if we could provide also a convenient way to print<br>
target properties for debugging purposes, something like<br>
<br>
cmake_print_properties(Foo::Foo_Libraries PROPERTIES INCLUDE_DIRS BLUB ... )<br>
<br>
Alex<br>
<div class=""><div class="h5">--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I strongly agree with Alex here. The union/sum of all of our end user's perspectives is much more important to consider than our own convenience as CMake developers.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mysteriously changing the target_link_libraries implementation to automatically do a bunch of stuff BY DEFAULT that it didn't used to do violates the principle of least surprise big time. I don't think it's a good idea.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">D</div><div class="gmail_extra"><br></div>