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

[J Decker]

On Wed, Dec 10, 2014 at 2:14 AM, Tim Blechmann <tim at klingt.org> 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 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.
>
> No more inconvenient than building any other target... from the command
line cmake --build . <--target install / instead of blank>; or 'make
install' instead of 'make'
click and build in a gui environment; again not a big issue... and can just
select that as the default target anyway... again just a modification to
workflow.  If it was a base library everything will be rebuilt
appropriately and nothing more or less.. just one extra copy step that's
pretty quick... and even that only copies what it needs to.
So I don't know why you would attribute that as a negative 'pretty
inconvenient' when it's really just a thing that just is... nature of the
beast

although now that you mention it; it would be nice to define install as the
default 'all' project.  Or do something really rude that would make every
target depend on install such that building a sub-executable would still
trigger the install script phase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141210/d1d349d2/attachment.html>