Actually I implemented yesterday a way how to copy the shared libs - with
configure_file() and a lot of frickling around with the lib names myself, like
finding out the extension on Linux and Windows, etc.
Now I tried to include the following command in the "shlibbiConfig.cmake.in"
file:
install(TARGETS shlibbi::SHLIBbi
EXPORT
shlibbi-targets
LIBRARY DESTINATION
${CMAKE_INSTALL_LIBDIR})
With this, I would expect that I am not "copying files", but "installing
targets" - so actually a more abstract and powerful level - if it works! Since
the generated shlibbiConfig.cmake would finally run in the context of the
importing project, i.e. during a find_package() call, it should actually
transfer the lib files from that imported target into the CMAKE_INSTALL_LIBDIR
of the calling project - so exactly what I need.
However, the result is an error message:
install TARGETS given target "shlibbi::SHLIBbi" which does not exist.
Well, it exists, because it is generated in the auto-generated
shlibbiTargets.cmake file like this:
add_library(shlibbi::SHLIBbi SHARED IMPORTED)
and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the
above install(TARGETS...) call.
Conclusion: "imported targets" are not "fully valid targets", because while I
can now refer to that imported target, like with an #include ... in my source
code, or with a successful link to the library, but obviously I cannot
"install" that target.
So my question can be even more specified now: Is there a way around this
"install blockage" that would allow me to do the required transfer of the
shared library into the lib folder of the calling project - and then even
further also to the caller's calling project? I mean: with the effect of first
moving libshlibbi.so to the lib directory of the shlibbu project, and then both
the libshlibbi.so and the libshlibbu.so to the example project - of course
including the required adaptation of the RPATH
Because that is what I learned: doing the transfer with install() instead of a
file copy through configure_file gives me not only the more abstract level of
project organization, but also takes care of the RPATH...
Best regards,
Cornelis
Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis <corne...@bockemuehl.ch>
schrieb:
Thanks for that hint! But for me the RPATH stuff is only a supplement, because
in the context of a Paraview based project, most of my shared libs are plugins,
and for these PV comes with its own mechanism to find them. But then all the
more important is the question about actually copying the libs - to a specific
location where the plugin finding procedure finds them! Regards, Cornelis
--
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
