| 1 |
Hi, |
| 2 |
|
| 3 |
On Tue, Dec 26, 2017 at 12:55:40PM +0100, Michael Weiser wrote: |
| 4 |
|
| 5 |
> > I think the cmake patches are ok, I'll look into the ebuilds you |
| 6 |
> > mention. I'll sync whatever I can find in this area. |
| 7 |
> Actually, the cmake patch might be incorrect since it got lost on emaint |
| 8 |
> sync and I had to reconstruct it from memory. I'm sure about |
| 9 |
> CMAKE_BUILD_WITH_INSTALL_RPATH, CMAKE_INSTALL_RPATH, |
| 10 |
> CMAKE_INSTALL_RPATH_USE_LINK_PATH but I think I also dropped |
| 11 |
> CMAKE_INSTALL_NAME_DIR for llvm and clang. |
| 12 |
|
| 13 |
After some more playing with cmake I think I got it: We do want a |
| 14 |
minimal CMAKE_INSTALL_RPATH (with just the path this project's libraries |
| 15 |
get installed to) and CMAKE_INSTALL_RPATH_USE_LINK_PATH because of |
| 16 |
https://cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH. This way |
| 17 |
cmake will automatically add the directories of libraries that a project |
| 18 |
links against and that are outside the build directory. No idea how the |
| 19 |
first part can be done without help by the upstream source or the |
| 20 |
individual ebuilds though. |
| 21 |
|
| 22 |
We do most likely not want CMAKE_BUILD_WITH_INSTALL_RPATH and |
| 23 |
CMAKE_INSTALL_NAME_DIR because we now know it causes breakage and the |
| 24 |
benefit is still unclear. |
| 25 |
-- |
| 26 |
bye, Micha |
Archives