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

[Daniel Pfeifer]

2012/12/7 Stephen Kelly <steveire at gmail.com>

> 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. Like I said
> > though, I haven't analysed how much of the exports complexity comes from
> > the use of tll().
>
> 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.
>
> If target_link_libraries never sets the new properties (LINK_LIBRARIES and
> INTERFACE_LINK_LIBRARIES), the question in the 'link implementation is link
> interface' case remains: Should the exported link interface be populated by
> iface.Libraries (as set by tll()), or by the LINK_LIBRARIES property (as
> populated by a new command).
>
> We can't really just check if LINK_LIBRARIES exists and use it if so. That
> would mean that if the user starts with this:
>
>  target_link_libraries(foo bar)
>
> bar will be in the link interface when exported. If they then add a line:
>
>  target_link_libraries(foo bar)
>  target_use_targets(foo bing)
>
> bar will no longer be in the link interface when exported. Only bing will
> be.
>
> I think that would be even more complex for the user, and probably even
> more
> complex for us to implement and review, emit appropriate warnings etc.
>
> 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.
> That's also a reason not to add a new command, I think.


When we add a new command for this, we might use a clearer signature.

Let's have a look at the following code:

  target_link_libraries(${mytaget} lib1 lib2)

Noticed the typo in ${mytaget}? This variable may be expanded to an empty
string, which makes lib1 the first argument.
The behavior silently changes, no error is reported.

The following signature seems safer:

  target_use_interfaces(target1 ... INTERFACES my::lib1 my::lib2 ...)

Here, if the target is missing, it is clearly interpreted as an error. It
may also be possible to use the same interfaces in more than one target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20121211/716c73b1/attachment.html>