<html>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.<br /><br />Now I tried to include the following command in the "shlibbiConfig.cmake.in" file:<br /><br />install(TARGETS shlibbi::SHLIBbi<br />    EXPORT<br />        shlibbi-targets<br />    LIBRARY DESTINATION<br />        ${CMAKE_INSTALL_LIBDIR})<br /><br />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.<br /><br />However, the result is an error message:<br /> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">install TARGETS given target "shlibbi::SHLIBbi" which does not exist.</p><br />Well, it exists, because it is generated in the auto-generated shlibbiTargets.cmake file like this:<br /><br />add_library(shlibbi::SHLIBbi SHARED IMPORTED)<br /><br />and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the above install(TARGETS...) call.<br /><br />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.<br /><br />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<br /><br />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...<br /><br />Best regards,<br />Cornelis<br /><br />Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis <cornelis@bockemuehl.ch> schrieb:<br /> <blockquote type="cite" cite="@localhost"><div id="edo-message"><div>Thanks for that hint! But for me the RPATH stuff is only a supplement, because in<span style="font-size: inherit;"> 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.</span></div><div> </div><div><span style="font-size: inherit;">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!</span></div><div> </div><div><span style="font-size: inherit;">Regards, Cornelis</span></div></div></blockquote></html>