[cmake-developers] Setting the link interface and dependencies in one command

[Alexander Neundorf]

On Saturday 01 October 2011, Stephen Kelly wrote:
> Hi David,
> 
> This is related to my patch to set the link_interface_libraries to empty
> and to:
> 
> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
> 
> Quoting:
> > Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
> > By default, all libraries a target is linked agaonst are in the
> > LINK_INTERFACE, which leads to unnecessary dependencies and increased
> > load time.
> > The alternative would be not to set it to empty, and expect our
> > developers to take care of it. I think this is not realistic.
> > So I'm quite sure we still want that
> 
> David Cole wrote:
> > I'm going to say wait until Brad replies here, but I do not see a
> > problem with that, *if* it's actually necessary. (Other than the
> > obvious problem, which is that LINK_INTERFACE and
> > LINK_INTERFACE_LIBRARIES are very close to each other and people will
> > get them confused, and constantly be looking at the documentation to
> > try to figure out which is which... A distinguishing naming
> > difference, if you could come up with one, would be better. i.e.,
> > names where you can tell what the meaning is for each, without
> > referring to the documentation...)
> 
> set_target_libraries(foo
>   bar baz
>   LINK_DEPENDENCY_LIBRARIES
>   bat mar
> )
> 
> So bat and mar do not become part of the link interface libraries?
> 
> This is analogous to the IMPORTED_LINK_DEPENDENCY_LIBRARIES I think.
> 
> > I guess I don't fully understand what you're doing here. If the
> > libraries are necessary as actual dependencies, then why do they also
> > have to be in the "link interface libraries" list...? I thought that
> > list was just to indicate that you need the libraries, but that things
> > that link to your library do not need them.
> 
> Actually, I think the opposite is true. Things in the "link interface
> libraries" list are not actually linked against.
> 
> By putting things in the "link interface libraries" list you indicate that
> things that use your library also need to link against the things in the
> "link interface libraries" list.
> 
> > If they are actual, hard
> > dependencies, then how could things that link to your library *not*
> > need them, too?

If library bar internally uses symbols from foo, it needs to link against foo.
But if bar doesn't expose symbols from foo in its interface, and my executable 
hello links against bar, it doesn't also have to be linked against foo.
This saves startup time and other things. Packagers also like that.

There is a slight difference between using 
set_target_properties(LINK_INTERFACE_LIBRARIES) and target_link_libraries( .. 
LINK_INTERFACE_LIBRARIES ...).

target_link_libraries() handles the "debug" and "optimized" keywords properly 
when they appear in the list, while set_target_properties() doesn't know about 
the special meaning of those.
So set_target_properties() should not be used with ${FOO_LIBRARIES} variables 
coming from find-modules, since they may potentially contain the debug and/or 
optimized keywords.

Below is an email from August 2008, when we discussed this:

On Monday 11 August 2008, you wrote:
> Brad King wrote:
> > I propose extending the interface
> > 
> > of target_link_libraries:
> >   target_link_libraries(mytarget INTERFACE ${FOO_LIBRARIES})
> > 
> > The INTERFACE keyword tells target_link_libraries to store the libraries
> > in the LINK_INTERFACE_LIBRARIES* properties of the target.  The command
> > can support the 'optimized' and 'debug' keywords by constructing the
> > appropriate property values.  So, the command
> > 
> >   target_link_libraries(mytarget INTERFACE foo optimized bar debug bard)
> > 
> > would append to property values:
> >   LINK_INTERFACE_LIBRARIES += foo;bar
> >   LINK_INTERFACE_LIBRARIES_DEBUG += foo;bard
> > 
> > This approach has the following advantages:
> > 
> > 1.) The keywords do not appear in the properties, so user code that
> > 
> >     inspects the properties does not have to deal with them, and the
> >     internal implementation stays clean
> > 
> > 2.) The keywords keep their meaning in the target_link_libraries command
> > 3.) The parsing of FOO_LIBRARIES with keywords is done in C++
> > 4.) Specifying the LINK_INTERFACE_LIBRARIES propert(y|ies) looks more
> > 
> >     like normal linking.
> 
> Okay, I've committed changes to CMake HEAD in CVS implementing this
> interface.  We can beat on it to make sure it works before merging to
> the 2.6 branch.
> 
> This should let us completely avoid using IMPORTED targets to set up the
> LINK_INTERFACE_LIBRARIES for now.  Using CMake HEAD from CVS, try changing:
> 
>   set_target_properties(kdecore PROPERTIES
>     LINK_INTERFACE_LIBRARIES "${kdecore_LINK_INTERFACE_LIBRARIES}"
>     )
> 
> to
> 
>   target_link_libraries(kdecore
>     INTERFACE ${kdecore_LINK_INTERFACE_LIBRARIES}
>     )
> 
> If things work as I expect, the optimized.lib problem on Windows should
> go away.
> 
> -Brad

Alex