On 09/28/2016 04:09 PM, Ruslan Baratov via cmake-developers wrote: > `<libname> -Wl,-rpath,<libdir>` to CMAKE_EXE_LINKER_FLAGS.
That adds it in a way that hides its presence from CMake. CMake has its own way to specify RPATH entries in the build tree. It will replace the build-tree-only entries with install-tree-only entries (if any) during installation. Any entries it doesn't know about are assumed to be added by the toolchain and are thus preserved. If one uses target_link_libraries to link each executable explicitly to the shared library via absolute path to the library file then IIRC CMake will put the RPATH in the build tree for that and remove it on installation. > adding new one, like CMAKE_INSTALL_DELETE_RPATH? We don't actually define any kind of first-class RPATH-update operation. It is only an implementation detail that we edit the RPATH on installation. In principle the design is that there is a build tree RPATH and an install tree RPATH. On non-ELF platforms we actually need to re-run the linker to produce the install tree version. Therefore CMAKE_INSTALL_DELETE_RPATH would not fit within our model. Instead one could add a BUILD_RPATH target property with CMAKE_BUILD_RPATH variable that specifies additional entries to put in the build tree RPATH. This would be the build-tree equivalent to the INSTALL_PATH target property. -Brad -- 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
