On Tue, Sep 23, 2014 at 12:53 PM, Nils Gladitz <[email protected]> wrote:
> On 23.09.2014 18:27, Roland Schulz wrote: > > > >> So I am thinking opt-in (target property) wrapper binaries that take the >> place of the actual binaries. > > > Why do you prefer that solution over a batch script or a manifest? > > > I looked at manifests but as far as I can tell they won't allow loading > libraries from arbitrary locations. > File references next to manifests are not allowed a path component. > I think you're right. There seems to be robust way to refer to DLLs in arbitrary locations. It only works well if the DLL has a manifest in its location, because one can refer to other manifests in arbitrary locations. But that wouldn't be a general solution. Executable wrappers can be drop in replacements for the actual executables > and I was considering AddDllDirectory() over modifying PATH hoping that is > less intrusive. > Seems reasonable. Have you got a solution to the problem you mentioned in your first email: I suppose it might be slightly more complex given that the import > library that is being linked to and the DLL that corresponds to the > import library might not be in the same location (and cmake might know > the location of the one but not always the location of the the other). > On windows when you deploy to a system different from your own it is > expected and common practice that you deploy your runtime requirements as > well. > You can not expect a preexisting installation of your library requirements > nor can you expect them to be in the same location as in your development > system. > I think you are referring to making a binary cpack installation package. I was thinking about installing on the build system. Then It would still be different from the build directory. Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309
-- 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
