Re: [cmake-developers] Exporting an imported target not supported?
> We have not thought deeply through the semantics of that in general. > One of the main challenges is relocation handling. Targets installed by the > project have known locations relative to the install prefix and we expect > that everything gets relocated together. Targets from external places have > no such relationship. Sure, this only works in case the locations are known. In my case, extlib is coming from a custom debian package, which locks its location. Another usage scenario could be to actually install (make a copy of) the imported library as it would be compiled from the tree. Not generally a preferable solution but there are some use cases I could think of. > If you're hard-coding paths anyway then I suggest simply linking via absolute > path instead of using an imported target. > If you do need usage requirements, do it through a non-imported interface > library: True, this is a good tip I could consider. My mind was stuck with IMPORTED :) -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
Re: [cmake-developers] Exporting an imported target not supported?
On 3/12/19 9:55 AM, Lassi Niemistö wrote: > is there a technical reason why it would not be a good idea to > allow exporting the imported targets with all their properties? We have not thought deeply through the semantics of that in general. One of the main challenges is relocation handling. Targets installed by the project have known locations relative to the install prefix and we expect that everything gets relocated together. Targets from external places have no such relationship. If you're hard-coding paths anyway then I suggest simply linking via absolute path instead of using an imported target. If you do need usage requirements, do it through a non-imported interface library: ``` add_library(extlib INTERFACE) target_link_libraries(extlib INTERFACE /path/to/libextlib.so) target_compile_definitions(extlib INTERFACE ...) ``` That can be installed and exported, and the importing side will simply use the same absolute path. -Brad -- 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
Re: [cmake-developers] Exporting an imported target not supported?
> The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code > to re-create the extlib imported target > with whatever usage requirements it had for building tree1. See the patch > below. > In combination with removing all the `extlib_interface` code, the `test.sh` > script passes. > Generally imported targets are not manually created by project code. > Instead they come from `find_package(MyDependency)`. Tree1Config should > repeat `find_package(MyDependency)` for > public-facing dependencies. If you don't want to create a complete find > module for extlib, you can create a normal > module that gets `include()`d from both places. I see. In my case extlib is really an external lib which does not provide any cmake helpers (finder modules / configs) so I need to write them myself. I wish to totally hide the need of extlib from tree2 perspective and not call its finders there. Actually, I would like to not care about it even at the point of exporting mylib, as extlib is a tiny tiny sub-sub-dependency of mylib. I would like to do this via modern target base cmake approach together with export mechanisms. Needing to also provide parts of my tree1 cmake code for tree2 kind of breaks this abstraction. Just being able to export all the imported targets as well would be cool, but seems that the workaround I did is actually pretty close. Posted an iterated version https://gitlab.com/lassi.niemisto/cmake_import_case/commit/9f6a26284835ab272dcc8acd5bfde144e73fafe8 Thanks for all the rubberducking! I think this solution suffices. Just one more question: is there a technical reason why it would not be a good idea to allow exporting the imported targets with all their properties? -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
Re: [cmake-developers] Exporting an imported target not supported?
On 3/12/19 6:57 AM, Lassi Niemistö wrote: > 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. The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code to re-create the extlib imported target with whatever usage requirements it had for building tree1. See the patch below. In combination with removing all the `extlib_interface` code, the `test.sh` script passes. Generally imported targets are not manually created by project code. Instead they come from `find_package(MyDependency)`. Tree1Config should repeat `find_package(MyDependency)` for public-facing dependencies. If you don't want to create a complete find module for extlib, you can create a normal module that gets `include()`d from both places. See the docs here: https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file -Brad ``` diff --git a/cmake_test_system_lassi/tree1/Tree1Config.cmake b/cmake_test_system_lassi/tree1/Tree1Config.cmake index 45f31f3..65248f3 100644 --- a/cmake_test_system_lassi/tree1/Tree1Config.cmake +++ b/cmake_test_system_lassi/tree1/Tree1Config.cmake @@ -1 +1,4 @@ +add_library(extlib SHARED IMPORTED) +set_target_properties(extlib PROPERTIES IMPORTED_LOCATION /tmp/cmake_test_system_lassi/extlib/build/libextlib.so) +target_include_directories(extlib INTERFACE /tmp/cmake_test_system_lassi/extlib/) include("${CMAKE_CURRENT_LIST_DIR}/Tree1Targets.cmake") ``` -- 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
Re: [cmake-developers] Exporting an imported target not supported?
> 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