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

Reply via email to