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
Re: [cmake-developers] Exporting an imported target not supported?
On 3/11/19 8:50 AM, Lassi Niemistö wrote: > I cannot see any automatic rpath-link generation if I try the above. Should I? Please post a minimal example tarball showing your case in practice. -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?
> For your use case, CMake does have logic to generate -rpath-link flags to > find dependencies of linked shared libraries, but it needs to know about > these dependencies. > Here is how to handle this: > * Tree1 creates an imported target `extlib`. > It is *not* installed or exported. > * Tree1 creates, exports, and installs, `lib1.so` with a dependency > on `libextlib.so.1`. This creates a `Tree1Targets.cmake` file. > Tree1 should also provide a `Tree1Config.cmake` file that includes > the targets file. See > https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file > * Tree1Config.cmake *also* creates imported target `extlib`. > This will be loaded in the context of dependents. > * Tree2 does `find_package(Tree1)`. This loads `Tree1Config.cmake` > which brings in both `extlib` and `lib1`. Now the -rpath_link flag > can be created by CMake. I cannot see any automatic rpath-link generation if I try the above. Should I? If I instead continue to add it manually with target_link_options to extlib, I would still need to link extlib in INTERFACE mode to lib1 to get those link options propagated, which again prevents me from exporting lib1 since extlib is not in the "export set". -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/8/19 1:11 AM, Lassi Niemistö wrote: > Am I just missing something and should be able to install the export > of “extlib” without installing the target itself? Any reasoning why > imported targets should not be possible to export? Any other solution > ideas for passing the custom link dir of imported lib nicely from tree to > tree? For your use case, CMake does have logic to generate -rpath-link flags to find dependencies of linked shared libraries, but it needs to know about these dependencies. Here is how to handle this: * Tree1 creates an imported target `extlib`. It is *not* installed or exported. * Tree1 creates, exports, and installs, `lib1.so` with a dependency on `libextlib.so.1`. This creates a `Tree1Targets.cmake` file. Tree1 should also provide a `Tree1Config.cmake` file that includes the targets file. See https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-a-package-configuration-file * Tree1Config.cmake *also* creates imported target `extlib`. This will be loaded in the context of dependents. * Tree2 does `find_package(Tree1)`. This loads `Tree1Config.cmake` which brings in both `extlib` and `lib1`. Now the -rpath_link flag can be created by CMake. -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
[cmake-developers] Exporting an imported target not supported?
Hello, Related to my recent crash report and its fix https://gitlab.kitware.com/cmake/cmake/merge_requests/3071 I struggle with exporting an imported target and according to the commit message it seems I will not be able to do that. Use case: · Tree1 needs an external lib libextlib.so from /path/to/lib which is not a system path. Thus Tree1 creates an imported target "extlib" of it · Tree1 provides a library "lib1", links it to "extlib" and installs+exports "lib1" · Tree2 imports Tree1 export file and tries to make "myexe" which would link to "lib1". Which is fine. · Problem: linker for "myexe" needs to link to the soname of "extlib", e.g. libextlib.so.1 and it cannot find it because it is not in a system path · Solution1: Add /path/to/lib as a link_directory in Tree2. I dislike the solution as Tree2 should not need to know this · Solution2: Try to get /path/to/lib inherited in target properties all the way from "extlib" -> "lib1" -> "myexe" using target_link_directories. This fails due to those directories passed to linker via -L which is not used to find library _dependencies_ · Solution3: Add -rpath-link /path/to/lib with target_link_options to "extlib" in Tree1 so that it would get inherited all the way to "myexe". It does not seem to inherit if "lib1" links to "extlib" in PRIVATE mode. Thus I need to link it "PUBLIC" which would require me to export the imported target "extlib". o If I do not install the target "extlib", I see no way to place it in the "export set" which makes the install of "lib1" to fail due to their PUBLIC linkage Am I just missing something and should be able to install the export of "extlib" without installing the target itself? Any reasoning why imported targets should not be possible to export? Any other solution ideas for passing the custom link dir of imported lib nicely from tree to tree? -Lassi Niemistö -- 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
