On 16. Jul, 2009, at 14:45, Eric Noulard wrote:

2009/7/16 Hendrik Sattler <[email protected]>:
Zitat von Michael Wild <[email protected]>:

Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
problem, as the binaries are located in
"${CMAKE_INSTALL_PREFIX}/bin/mcrl2".


On Mac you can set the INSTALL_NAME_DIR property (or the
CMAKE_INSTALL_NAME_DIR variable) to something starting with
@executable_path, to the same effect as above.

So maybe the proper value can be made available as variable? Or direct
support in cmake with some boolean variable?

Small message to say that I would find this a good feature request.

Like:
CMAKE_RELATIVE_RPATH_SUPPORTED true/false
CMAKE_RELATIVE_RPATH_PREFIX:
 Linux: "$ORIGIN"
 MacOS: "@executable_path"
Anything else?

Honestly, I don't think this is necessary. What is so complicated about this?

set(CMAKE_INSTALL_NAME_DIR "@executable_prefix/../lib")
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")


May be there is some equivalent on Windows platform too
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
[just pointing the link, I'm really no windows expert and ....
don't want to become one :-) ]

Seriously, that platform is just plain broken if you ask me. __declspec(dllimport), __declspec(dllexport)?! What were they thinking? And DLL-exported C++ template instantiations with member templates simply don't work. Sometimes I marvel at why so many people go trough the pains of writing software for such a broken system...


May be worth a Wiki update too (even before the feature is
requested/implemented)
http://www.cmake.org/Wiki/CMake_RPATH_handling

ACK

Michael
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to