[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