[CMake] Copying shared libraries in a post-build step

[Tim Blechmann]

> This sounds more like an install phase... to bring the whole package
> together in one appropriate place.
> 
> if( WIN32 )
> INSTALL( TARGET <target> RUNTIME DESTINATION bin LIBRARY DESTINATION bin
> ARCHIVE DESTINATION lib )
> else( WIN32 )
> INSTALL( TARGET <target> RUNTIME DESTINATION bin LIBRARY DESTINATION lib
> ARCHIVE DESTINATION lib )
> endif( WIN32 )

on unixy platforms, shared libraries can be resolved using rpaths. on
windows this is not the case: if you link a dll into an executable the
executable will not run, unless the dll can be resolved at startup time.
the is typically done by placing he dll next to the exe.

the install step is a possible workaround, but in my experience this
implies that you have to run the install script in order to debug the
binary, which is pretty inconvenient.


> On Tue, Dec 9, 2014 at 3:38 PM, Walter Gray
> <chrysalisx at gmail.com
> <mailto:chrysalisx at gmail.com>> wrote:
> 
>     Hey all,
>     I'm working on a module that will allow me to automatically copy all
>     the required .dll files as defined by well-formed import library
>     targets to the appropriate location (same folder for windows,
>     Frameworks folder for OSX bundle, ect).  I've got the code that
>     scans an executable's INTERFACE_LINK_LIBRARIES property recursively
>     to find all such shared library, however I'm running into a small
>     problem.  I really like using file globbing in higher level source
>     directories to add all appropriate sub-directories, but this means
>     that sometimes a dependency will not be fully defined yet. This is
>     normally fine since these things are usually resolved at
>     *generation* time, but since I'm doing a manual traversal of the
>     list of link libraries at config time that's not really acceptable. 
>     I realize I could just not do the globbing and just make sure the
>     directories were setup in the correct order, but I really don't like
>     making the add_subdirectory calls order dependent.
> 
>     One solution I've come up with is to add the targets I want to do
>     this to to a global list, then iterate over that list as the last
>     step in my top-level cmake lists file, but that has the issue that I
>     can no longer use add_custom_command on those targets at that
>     point.  I'm wondering 3 things:
> 
>     1)What is the reasoning behind not allowing add_custom_command on
>     targets not defined in the current directory? Especially now that
>     SOURCE can be modified, the restriction seems very arbitrary.
> 
>     2)How stupid would it be to reserve the command using something like
>        add_custom_command(TARGET ${target} POST_BUILD COMMAND
>     $<TARGET_PROPERTY:COPY_SHARED_LIBS_COMMAND>)
>      then use set_property(TARGET ${target} APPEND PROPERTY
>     COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?
> 
>     3) Am I completely missing something and there's already a totally
>     well supported way of making sure that an executable's shared
>     library dependencies end up in the correct directory?  I couldn't
>     find a really satisfactory answer on stack overflow or the archives.
> 
>     Thanks!
> 
>     --
> 
>     Powered by www.kitware.com <http://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:
>     http://public.kitware.com/mailman/listinfo/cmake
> 
> 
> 
>