Hi Daniel~
" Suppose you have libA that optionally uses zip functionality (say by some
option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have
-lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake)."
I think the best way to handle this is to turn 'transitive library linking'
off. It seems to me that the use of zip functionality is an implementation
detail of libA, that no clients should be aware of. I do this in my projects
with a special form of the target_link_libraries( ) command:
`target_link_libraries( libA PRIVATE ${ZLIB_LIBRARIES} )`
I believe PRIVATE, PUBLIC, INTERFACE keywards were added in cmake 2.8.12
Kent
------------------------------
Message: 4
Date: Mon, 01 Jun 2015 11:03:53 +0200
From: Daniel Wirtz <daniel.wi...@simtech.uni-stuttgart.de>
To: cmake@cmake.org
Subject: [CMake] Conditional transitive link libraries
Message-ID: <556c1ff9.6040...@simtech.uni-stuttgart.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello all,
I'm struggling with the CMake "Config"-based package description when using two
depending packages where the upstream package has optional link libraries.
Suppose you have libA that optionally uses zip functionality (say by some
option USE_ZLIB in libA's CMakeLists.txt). This means libA will optionally have
-lz in its INTERFACE_LINK_LIBRARIES (exported into liba-config.cmake).
Now, if you have a libB using libA via find_package(libA), how do you know if
libA has been built with or without zlib support when both libraries are
installed and exported with CMake's package config system?
I know that the link library information is treated transitively and will be
propagated to the link libraries of libB, hence -lz will appear whenever
linking against libB. However, the PATH to libz is nowhere included;
consequently, the link fails with "could not find library z"
unless you magically knew that libz is a dependent link library of libA and
where to include it from. Including the absolute path to libz in libA's config
is also not the way to go, as it ruins the portability over different systems.
Is there a "native" CMake way?
Thanks!
--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044
--
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:
http://public.kitware.com/mailman/listinfo/cmake
