[cmake-developers] [CMake] Windows rpath emulation

[Roland Schulz]

On Tue, Sep 23, 2014 at 12:53 PM, Nils Gladitz <nilsgladitz at gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140923/ac020019/attachment-0002.html>