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