> Please post a minimal example tarball showing your case in practice. https://gitlab.com/lassi.niemisto/cmake_import_case
Instruction: * run the test.sh script, it will copy the test setup under /tmp/ and operate it there * by default everything should pass * go to cmake_test_system_lassi/tree1/CMakeLists.txt and comment out the line 25 * now running test.sh again fails Realizations during creating the minimal setup: * Talks about not being able to export library linked to an IMPORTED library in INTERFACE mode were bullcrap, sorry. I had still a secondary build mode enabled which created "extlib" in-tree as a regular library, which created this uninteresting "not in export set" error. So: exporting a library with IMPORTED dependencies is fine to CMake. * I understood that the -rpath-link is probably not what I want. It would help in case extlib was PRIVATE linked by mylib. But since PRIVATE linking would stop any properties of extlib to be inherited by mylib's users, it won't work. PUBLIC linking instead makes users of mylib to also link to extlib, which again benefits from target_link_directories, not -rpath-link. Bottom line question: What to do in order to get rid of the extlib_interface workaround? I have not yet seen any means of "exporting" the properties of an imported target to tree2. Thanks, -Lassi -- 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-developers
