[cmake-developers] [CMake] Windows rpath emulation

[David Cole]

What is the problem that this feature is trying to solve?

It seems unnecessary to me as a first-class feature of CMake. I must
be missing something...

But if you do pursue something like this, it seems to me that
install(TARGETS ...) should install all files including the wrapper.

Is this only for executable files, or would something like this also
be possible/necessary for shared libraries, too?

Slicer and ParaView do (or did in the past) have similar wrappers to
set up necessary environment variables before invoking the "real" exe.


Thanks,
David C.


On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz <nilsgladitz at gmail.com> wrote:
> On 09/20/2014 11:53 PM, Nils Gladitz wrote:
>>
>> On 20.09.2014 23:31, Roland Schulz wrote:
>>>
>>> it would be nice if there were a way to emulate rpath under Windows.
>>> As far as I can see there are two possible approaches:
>>> - Generate a shell script which sets PATH
>>> - Generate a manifest for the application and a manifest for the
>>> dependencies.
>>> http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an
>>> example of how to do it.
>
>
> So I am thinking opt-in (target property) wrapper binaries that take the
> place of the actual binaries.
>
> e.g.
>   # Initializes ENABLE_EXECUTABLE_WRAPPER target property
>   set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON)
>
>   add_executable(foo foo.cpp)
>
> Could produce
>   foo.exe.real        # Actual target binary
>   foo.exe.wrapper     # CMake generated configuration file
>   foo.exe             # Wrapper binary that reads "foo.exe.wrapper", sets up
> the environment and runs "foo.exe.real"
>
> COMMANDs (add_custom_command()/add_custom_target()/add_test()) could
> transparently call foo.exe (like they would have done without the wrapper).
>
> install(TARGETS) should ignore the wrapper and transparently install and
> rename the real binary.
>
> $<TARGET_FILE> should continue to point at the real binary.
> A new $<TARGET_WRAPPER> could point at the wrapper binary.
>
> The wrapper binary itself could be precompiled and included with cmake
> itself. It would determine which configuration to read and which binary to
> run by inspecting its own name.
>
> I primarily had windows native builds in mind.
> Are there additional use cases?
>
> 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