[CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language

[Cornelis Bockemühl]

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 <cornelis at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20191008/a64dd207/attachment.html>