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
