[CMake] The Windows equivalent of RPATH?

[Arjen Markus]

Alexander Neundorf wrote:

>-------- Original-Nachricht --------
>Datum: Fri, 22 Sep 2006 09:18:05 +0200 (CEST)
>Von: "Arjen Markus" <arjen.markus at wldelft.nl>
>An: cmake at cmake.org
>Betreff: [CMake] The Windows equivalent of RPATH?
>
>  
>
>>Hello,
>>
>>in the PLplot project we have run into an issue that is peculiar
>>to Windows:
>>
>>When you build the various libraries that PLplot consists of, they
>>end up in different directories (at least before installation).
>>On UNIX and Linux these directories are taken care of via the
>>RPATH mechanism, so that the example/test programs "know" where
>>to find them, without actual installation.
>>
>>On installation again the RPATH mechanism makes sure the
>>directories where the shared libraries live are known.
>>
>>On Windows, however, there is as far as I know, no such mechanism.
>>We need to rely on the search path for the DLLs to be found. And
>>currently that means that we need to copy the DLLs into the directories
>>holding the example/test programs (there are different directories
>>for all the programming languages we support). Otherwise the
>>example/test programs can not be run.
>>
>>My question is: what is the best way to solve this problem?
>>
>>I can see a couple of solutions:
>>- Copy the various DLLs via a custom target - now we do it manually
>>- Expand the path just before running the example/test programs
>>- (A brute force method would be to copy the DLLs into the system
>>  directory, but that is not acceptable to many people: pollution
>>  of the system directory, on many Windows machines this is not
>>  even allowed without special permissions etc.)
>>    
>>
>
>Two options:
>you can set EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH to the same directory, so they will end up in the same directory.
>Or you create wrapper bat-files which set PATH appropriatly.
>  
>
I like the first option - or at least the ability to control where the 
DLLs and the import libraries
end up.

Thanks,

Arjen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060925/3a023144/attachment.htm