On 09/23/2014 03:11 PM, David Cole wrote:
What is the problem that this feature is trying to solve?
Being able to run binaries with DLL dependencies within the build tree.
Basically the same thing that the build time RPATH feature does on e.g.
linux.
If you are e.g. linking to Qt5 (shared) and don't have the Qt5 bin
directory in your PATH the binary will not run since it can not locate
the DLL on its own.
As workarounds people often copy the DLLs into their build directories,
output all runtime files into a single directory and/or set up custom
wrappers that set up PATH.
But if you do pursue something like this, it seems to me that
install(TARGETS ...) should install all files including the wrapper.
CMake replaces build time RPATHs with installation RPATHs when deploying.
I think the same should apply to these wrappers. They are only useful
for a build tree.
Is this only for executable files, or would something like this also
be possible/necessary for shared libraries, too?
I have been pondering DLLs as well but would restrict it to executables
for now. For DLLs this probably only makes sense in a context where the
DLL is build by CMake and used as-is without deployment in a context
outside of CMake's control.
Also I am guessing this might not be as simple to set up as it is for
executables.
Thanks for the feedback!
Nils
--
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-developers
