FYI, this function appears to work for me with one caveat: there appears to be a bug where SYSTEM_INCLUDE_DIRECTORIES are not handled properly so you can't use this function if you need that property to be propagated.
I filed https://gitlab.kitware.com/cmake/cmake/issues/18940 for that. I think I'll submit this as an enhancement request and see what the CMake devs think of it. It could be there are issues that I haven't thought of. On Sat, 2019-02-16 at 17:46 -0500, Paul Smith wrote: > I wrote this function. At first attempt it seems to do what I want but > I've definitely not completed my work so I may well still find issues > with it. > > Basically it does everything that target_link_libraries() does (at > least, it tries to as best as I understand it other than a bunch of > properties I don't know what they are and don't use) with one caveat: > it adds libraries to INTERFACE_* but not LINK_LIBRARIES: > > function(static_link_libraries tgt mode) > foreach(lib ${ARGN}) > # Import all the source-level properties as normal > foreach(t COMPILE_DEFINITIONS COMPILE_FEATURES COMPILE_OPTIONS > INCLUDE_DIRECTORIES SOURCES SYSTEM_INCLUDE_DIRECTORIES) > if(${mode} STREQUAL "PRIVATE" OR ${mode} STREQUAL "PUBLIC") > set_property(TARGET ${tgt} APPEND PROPERTY > ${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>) > endif() > if(${mode} STREQUAL "PUBLIC" OR ${mode} STREQUAL "INTERFACE") > set_property(TARGET ${tgt} APPEND PROPERTY > INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>) > endif() > endforeach() > # Import all the library-level properties as INTERFACE only > foreach(t LINK_DEPENDS LINK_DIRECTORIES LINK_OPTIONS) > set_property(TARGET ${tgt} APPEND PROPERTY > INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>) > endforeach() > # Import the library itself as INTERFACE only > set_property(TARGET ${tgt} APPEND PROPERTY > INTERFACE_LINK_LIBRARIES ${lib}) > endforeach() > endfunction() > > > > On Sat, 2019-02-16 at 23:03 +0100, Andreas Naumann wrote: > > Hi Paul, > > > > I understand the relationship between libraries as strict, such that you > > always build all dependent libraries before. > > In your use case I thought about splitting the libraries in the actual > > target and the interface one. > > For example, you could create an interface library foo_interface > > add_library(foo_interface INTERFACE ) > > set the properties and then link foo and bar to this interface library > > using target_link_libraries. > > > > But be aware, that now every executable, which links against bar must > > manually link against foo. If your project is large, this seems not > > really desirable. But I think you could also split the library bar in > > two bar_withoutFoo and bar. The library bar_withoutFoo would link > > against foo_interface and compile the sources, whereas bar is an > > interface library which depends on bar_withoutFoo and foo. > > The developer could than build bar completely independent from foo and > > you could transport the transitive dependencies to the executable. > > > > I don't know if this doubled structure using pure interfaces libraries > > and the actual libraries is maintainable. > > > > Hope that helps a bit, > > Andreas > > > > Am 16.02.19 um 20:20 schrieb Paul Smith: > > > Hi all; > > > > > > I'm working on modernizing our large complex CMake environment. It > > > builds a number of different binaries from an even larger number of > > > static libraries, and these libraries depend on each other as well, in > > > that they need to include headers and, sometimes, -D options etc. > > > > > > I've used straightforward target_link_libraries() to declare the > > > relationship between these libraries; for example: > > > > > > add_library(foo STATIC ...) > > > target_include_directories(foo PUBLIC ...) > > > target_compile_definitions(foo PUBLIC ...) > > > target_compile_options(foo PUBLIC ...) > > > > > > add_library(bar STATIC ...) > > > target_link_libraries(bar PUBLIC foo) > > > > > > add_executable(one ...) > > > target_link_libraries(one PRIVATE bar) > > > > > > This works, in that everything builds properly but it has a side-effect > > > we want to avoid. Because the source tree is large many developers > > > have a habit of testing compilation of subsets of the code using > > > something like: > > > > > > make -jX bar > > > > > > and expect it to just build the static library bar. Because it's a > > > static library you don't need to actually build "foo" until link time. > > > But we do need all the include directories, compile definitions, and > > > compile options to be inherited from "foo" into "bar". > > > > > > However with the above formulation, building "bar" also forces the > > > compilation of "foo", which we don't need or want. > > > > > > I've played around with the different values of PUBLIC, PRIVATE, and > > > INTERFACE but there doesn't seem to be a straightforward way to say, > > > "take the interface values for includes, definitions, and options, but > > > don't depend on the generated target". > > > > > > I can write a function to do this myself but this seems like the most > > > common way someone would want to treat static libraries referencing > > > other static libraries, so I wondered if I was missing something > > > that would allow this in a simpler way. > > > > > > Thanks! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
