>> 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.
On Tue, Oct 9, 2018 at 8:18 AM Hendrik Greving <
hendrik.greving@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):
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
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
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
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
>
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 $ $)?
On Thu, Sep 27, 2018 at 5:03 PM 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
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
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
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 <
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
12 matches
Mail list logo
