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

Stephen Kelly steveire at gmail.com
Tue Oct 4 22:22:18 EDT 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.
> 


The sideline discussion about linking seems to be finished, so I'm bumping 
the idea of being able to specify both the non-exposed dependencies and the 
exposed dependencies in one command without repetition.

I see three options:

1) Change the meaning of LINK_INTERFACE_LIBRARIES in 

set_target_properties(foo LINK_INTERFACE_LIBRARIES bar)

to not just communicate that users of foo should also link against bar, but 
make that command actually link foo against bar. I don't know if there is 
any use case for the existing behaviour. This could be done with a CMake 
policy. It would then be very trivial to make 

set_target_properties(foo baz LINK_INTERFACE_LIBRARIES bar)

mean 'foo links against baz, but doesn't expose symbols from it; foo links 
against bar, and does export symbols from it'.

2) Introduce another variable for doing the same thing as above. As David 
notes, this might be confusing without looking up docs (though it wouldn't 
be the first part of CMake that needs docs to use). Also, if the existing 
behaviour of LINK_INTERFACE_LIBRARIES (do not actually link to the things 
listed there) doesn't have a use-case, or is rare, that one would fall out 
of use, and the new one would be more commonly used (it is good to optimise 
for the common case).

3) Introduce a variable for doing the opposite of what 
LINK_INTERFACE_LIBRARIES does. That is, the equivalent of the above would be

set_target_properties(foo bat LINK_DEPENDENT_LIBRARIES baz)

(note that bat and baz are swapped). This form communicates that baz should 
be linked against foo, but users of foo do not need to link against baz.


My preference is (1). Does anyone know the reason for the current behaviour?

Thanks,

Steve.






More information about the cmake-developers mailing list