[CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov]

On 01-Dec-15 03:51, Alexander Neundorf wrote:
>
> On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote:
>
> > On 30-Nov-15 09:10, Dmitry Marakasov wrote:
>
> > > Hi!
>
> > >
>
> ...
>
> > > The best solution would be for cmake to fix path in executable file
>
> > > right after installation, something similar to what cmake does with
>
> > > rpaths.
>
> >
>
> > I doubt there is a general way to patch data section with string in
>
> > executable. At least with different size and in safe manner. For example
>
> > Clang is smart enough to figure out 'strlen' of literal string at
>
> > compile time, so changing string affects logic and hence is dangerous.
>
> > And rpaths unlike data is designed to be modifiable
>
> Not really. CMake has extra code to make sure the build rpath is as 
> long as the install rpath will be, so it can be patched in later.
>
Well, that's exactly what I said - RPATH can be patched.

> > (e.g. see
>
> > install_name_tool for OS X) so it's okay to hack it back and forth.
>
> >
>
> > Second thought is that when you hardcode path in executable you make it
>
> > non-relocatable.
>
> E.g. on Linux $ORIGIN could be used in the RPATH.
>
> Alex
>
It's not about RPATH, it's about string literal with path in C++ code. 
E.g. if you have:
const char* resources = "/usr/share/foo"

and installing your package to "/home/username/tools" then executable 
will not find resources since there is no files in "/usr/share/foo"

Ruslo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151201/94535f21/attachment.html>