Let me just mention up-front that I spent about 2 weeks earlier this year completely converting our circa-2011 cmake environment to ultra- modern cmake: switching completely to TLL, interfaces, removing virtually all if-statements and converting them into generator expressions, etc. So I'm very familiar with CMake's model for PRIVATE, PUBLIC, and INTERFACE and how inheritance works.
And, I see the paradigm you're operating under where a shared library provides a single "interface" that is public. But, that's not the only way to use shared libraries. I'm trying to collect a number of static libraries with different interfaces into a single shared library that can be linked with executables (in my case I have 220 unit test programs which, when linked statically, not only take a very long time and a lot of memory, but use about 45G of disk space per build--I am collecting these into a shared library that can be linked with our unit tests. In my testing this reduces the size of a sample unit test executable from 400M down to about 8M). So: I need my shared library to export a combination of ALL the public interfaces of the static libraries it was built from, but not, obviously, export the static libraries themselves. On Sat, 2019-06-15 at 23:10 -0700, Craig Scott wrote: > The behaviour is correct according to what you are telling CMake to > do. If you use PUBLC in a target_link_libraries() call, you are > saying that anything that links to your shared library should also > link to the static library. That simply does not make sense, from the point of view of how a program and a linker work (I understand it's how CMake works). Let me work backwards, starting with a fact that hopefully we can all agree on: It is NEVER appropriate to put a static library into the INTERFACE_LINK_LIBRARIES of a shared library. I'd be interested to hear counter-arguments, but even if there are any reasons for it my position is that in those very rare cases you should be listing the static library in the TLL of the executable directly. If we can agree on that, then using the current rules of CMake inheritance this implies that we can NEVER add a static library as a PUBLIC TLL for a shared library. Which seems, to me, quite ridiculous because why shouldn't you want to allow INTERFACE_COMPILE_DEFINITIONS, INTERFACE_COMPILE_OPTIONS, and INTERFACE_COMPILE_DIRECTORIES of the static library to be inherited by the shared library into its PUBLIC interface? That seems like a quite reasonable thing to want to do. -- 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
