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. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers