LOCATION target property, generator expressions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

LOCATION target property, generator expressions

Hendrik Greving
Hello,

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). In order to update our cmake w.r.t. CMP0026, I don't know how to get LINK_FLAGS consume a generator expression. In other cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and reading the file to obtain 'var' worked. Thanks in advance!

--

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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Marc CHEVRIER
LINK_FLAGS does not support expressions.
However, property LINK_OPTIONS (and INTERFACE counterpart) support generator expressions. These properties are new for version 3.13 which will be available soon (probably next month).
Le mer. 26 sept. 2018 à 05:21, Hendrik Greving <[hidden email]> a écrit :
Hello,

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). In order to update our cmake w.r.t. CMP0026, I don't know how to get LINK_FLAGS consume a generator expression. In other cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and reading the file to obtain 'var' worked. Thanks in advance!
--

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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
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. For CMP0026, I'd like to get rid of LOCATION. As pointed out earlier, unclear how this would work e.g. by using file(GENERATE.. in this case.
Thanks in advance

On Tue, Sep 25, 2018, 10:45 PM Marc CHEVRIER <[hidden email]> wrote:
LINK_FLAGS does not support expressions.
However, property LINK_OPTIONS (and INTERFACE counterpart) support generator expressions. These properties are new for version 3.13 which will be available soon (probably next month).
Le mer. 26 sept. 2018 à 05:21, Hendrik Greving <[hidden email]> a écrit :
Hello,

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). In order to update our cmake w.r.t. CMP0026, I don't know how to get LINK_FLAGS consume a generator expression. In other cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and reading the file to obtain 'var' worked. Thanks in advance!
--

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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Relative RPATH for installation (was: LOCATION target property, generator expressions)

Brad King
On 09/27/2018 08:03 PM, Hendrik Greving 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.

CMake puts in absolute RPATH values in the build tree to make things run
there.  There is a separate INSTALL_RPATH target property that can be
set to the RPATH to be used in the install tree.  Since your install
rules control the relative layout in the install tree independent of the
build tree layout, then your project code can set INSTALL_RPATH to
$ORIGIN/... as needed for wherever it installs things.

-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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
In reply to this post by Hendrik Greving
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Brad King
On 10/02/2018 01:12 PM, Hendrik Greving wrote:
> By the way, the new generator expression support in 3.13, is this for
> LINK_FLAGS or LINK_OPTIONS.

LINK_OPTIONS, though it should be used through target_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>)?

No, that level of logic is not possible with generator expressions.

I really don't think you should need to do that though.  CMake handles
RPATH in the build tree automatically.  In the install tree you can set
INSTALL_RPATH to whatever relative layout of files you use in your
install rules, which you also control.  If that is not sufficient then
please explain your use case in more detail.  I've never seen this
requirement before.

-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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Sattler
In reply to this post by Hendrik Greving

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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
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 <[hidden email]> 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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Craig Scott-3


On Tue, Oct 9, 2018 at 8:18 AM Hendrik Greving <[hidden email]> 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):


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:



 

On Thu, Oct 4, 2018 at 2:24 PM Hendrik Greving <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]> 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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: LOCATION target property, generator expressions

Hendrik Greving
>> 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.

We're doing this already, but this doesn't solve the problem. The project is a collection of libraries and binaries and until now (i.e. using LOCATION), we could compute the relative paths from binary to its libraries in the makefiles and append to rpath in linker flags (i.e. see above)

On Mon, Oct 8, 2018 at 2:31 PM Craig Scott <[hidden email]> wrote:


On Tue, Oct 9, 2018 at 8:18 AM Hendrik Greving <[hidden email]> 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):


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:



 

On Thu, Oct 4, 2018 at 2:24 PM Hendrik Greving <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]> 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


--

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