[cmake-developers] [CMake] Windows rpath emulation

[Nils Gladitz]

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.

Libraries could at best be put in direct subdirectories next to the 
consuming executables.

Executable wrappers can be drop in replacements for the actual 
executables and I was considering AddDllDirectory() over modifying PATH 
hoping that is less intrusive.

>
> On Tue, Sep 23, 2014 at 9:24 AM, Nils Gladitz <nilsgladitz at gmail.com 
> <mailto:nilsgladitz at gmail.com>> wrote:
>
>     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.
>
>
> Why only for the build tree? Even after installing not all DLLs might 
> be in install folder. Or would you recommend to always copy all DLLs? 
> Even things like for e.g. for MingW the libgcc*dll?

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.

Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140923/4889e099/attachment-0002.html>