Is there a good place to record the feature request (- if ack'd -)? gitlab
issue?
Thanks!
On Thu, Oct 4, 2018 at 2:24 PM Hendrik Greving <
hendrik.greving....@gmail.com> wrote:
> Hi, we would like to..
> (*) keep modularity and flexibility (i.e. avoid hard-coding relative
> paths) w/ binaries and libraries in build tree at flexible locations.
> (*) update rpath in the target binary based on relative paths from
> $ORIGIN, such that a user or any other script can move the build (and later
> install) tree.
> The project (DynamoRIO) has multiple libraries and multiple target
> binaries such that the CMAKE* solution (and thanks for that in any case)
> above would not work for all of them. LOCATION and file(RELATIVE..)
> provided that functionality. With CMP0026 and LOCATION going away, there
> seems to be no substitute for this, even w/ 3.13 it sounds like we still
> couldn't compute the relative path(s). Would it be feasible for me to put
> in a feature request in cmake?
>
>
> On Wed, Oct 3, 2018 at 11:28 PM Hendrik Sattler <p...@hendrik-sattler.de>
> wrote:
>
>>
>> Hi,
>>
>> You can use the following cmake snippet right below the project()
>> command to add proper RPATH values:
>> include ( GNUInstallDirs )
>> if ( CMAKE_SYSTEM_NAME STREQUAL "Linux" )
>> list ( APPEND CMAKE_INSTALL_RPATH
>> "\$ORIGIN/../${CMAKE_INSTALL_LIBDIR}" )
>> endif ( CMAKE_SYSTEM_NAME STREQUAL "Linux" )
>> set ( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE )
>>
>> This assumes, libraries are installed to CMAKE_INSTALL_LIBDIR and
>> programs to CMAKE_INSTALL_BINDIR.
>> Additionally you may add the following line to disable a change in the
>> binary files during install target run:
>> set ( CMAKE_BUILD_WITH_INSTALL_RPATH ON )
>>
>>
>> The latter might be useful when splitting of debug symbols on ELF
>> platforms in post-build. However, it disables running the binaries in
>> the build tree.
>>
>>
>> CMake supports PDB files but split dbgsym file are (strangely) not
>> supported out-of-the-box.
>>
>> HS
>>
>>
>> Zitat von Hendrik Greving <hendrik.greving....@gmail.com>:
>>
>> > By the way, the new generator expression support in 3.13, is this for
>> > LINK_FLAGS or LINK_OPTIONS. And regardless of the former, will it be
>> > possible to compute a relative path based on generator expressions, i.e.
>> > file(RELATIVE $<TARGET_FILE_DIR:mytarget>
>> $<TARGET_FILE_DIR:mytargetlib>)?
>> >
>> > On Thu, Sep 27, 2018 at 5:03 PM Hendrik Greving <
>> > hendrik.greving....@gmail.com> wrote:
>> >
>> >> Thanks. Ok one step back. What we want is to have the same relative
>> path
>> >> from binary/executable to linked library in build and install tree
>> (which
>> >> we assume is the same for us). Looks like by default, e.g. cmake 3.9,
>> puts
>> >> in an absolute path. The current (c-)makefiles compute the relative
>> part of
>> >> an executable -> library by using LOCATION and add this to
>> >> -Wl,-rpath=$ORIGIN/[relative part]. We want to do the same w/o LOCATION
>> >> (i.e. resolving CMP0026)
>> >>
>> >> On Thu, Sep 27, 2018 at 7:29 AM Brad King <brad.k...@kitware.com>
>> wrote:
>> >>
>> >>> On 09/26/2018 10:23 AM, Hendrik Greving wrote:
>> >>> > Is there any way before 3.13 to achieve what I need? Right now we
>> >>> > modify LINK_FLAGS based on something that is computed with values
>> >>> > from LOCATION.
>> >>> [snip]
>> >>> > our cmake setup is using LOCATION property for two targets to
>> compute
>> >>> > a relative path from these two, and adds this to LINK_FLAGS
>> >>> > (for rpath, but irrelevant in this context).
>> >>>
>> >>> To at least see if 3.13 will support your use case, you could
>> >>> try a nightly binary from here:
>> >>>
>> >>> https://cmake.org/files/dev/?C=M;O=D
>> >>>
>> >>> Use `$<TARGET_FILE_DIR:mytarget>/..` to refer to a path relative
>> >>> to the target file location.
>> >>>
>> >>> I've never seen a need to adjust link flags based on the target
>> >>> location. CMake has several features for RPATH support. What
>> >>> are you really trying to do?
>> >>>
>> >>> -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:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
--
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:
https://cmake.org/mailman/listinfo/cmake
