[CMake] LOCATION target property, generator expressions

Mon Oct 8 17:30:52 EDT 2018

On Tue, Oct 9, 2018 at 8:18 AM Hendrik Greving <
hendrik.greving.smi at gmail.com> wrote:

> Is there a good place to record the feature request (- if ack'd -)? gitlab
> issue?
> Thanks!
>

Gitlab is the place to record feature requests (and to check for existing
ones):

https://gitlab.kitware.com/cmake/cmake

Relocating build trees is not supported in general by CMake, it embeds
absolute paths in various places. I doubt this is likely to change. If you
want to relocate an *install* directory, you should either:

   - Ensure the installed products themselves are relocatable (which is a
   good goal in itself), or
   - Simply install again to the new location rather than move the
   installed directory.

A strategy I've seen used before is to arrange for all the build outputs
(libraries, executables) to end up in a directory structure that mimics the
installed layout. This can be helpful if the applications expect to find
things at some specific location relative to themselves at run time. It can
be a bit finicky and doesn't play well with multi-config generators like
Xcode or Visual Studio (due to them adding a config-specific directory to
the directory structure), but maybe it is an option to consider (I'd
personally avoid it if I can though).

Not sure if it is relevant here, but there has also been some recent
discussions going on regarding the use of relative RPATH in the build tree,
but that's more to do with making builds reproducible:

https://gitlab.kitware.com/cmake/cmake/issues/18413

>
> On Thu, Oct 4, 2018 at 2:24 PM Hendrik Greving <
> hendrik.greving.smi at 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 <post at 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.smi at 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.smi at 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.king at 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
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20181009/35f4b817/attachment-0001.html>