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

[Brad King]

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