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

[J Decker]

Mind you 'install' doesn't have to be '/usr' or 'program files/whatever'
but could be 'output' which will be relative to ${CMAKE_BINARY_DIR} if not
absolute


On Tue, Dec 9, 2014 at 4:15 PM, J Decker <d3ck0r at gmail.com> wrote:

> 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 Tue, Dec 9, 2014 at 3:38 PM, Walter Gray <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
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141209/931d2e83/attachment.html>