[cmake-developers] Setting include directories via target_link_libraries() ?

[Stephen Kelly]

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.