[CMake] Best way to handle application data path for local run vs. installation
Alexander Neundorf
a.neundorf-work at gmx.net
Tue Dec 1 17:13:04 EST 2015
On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote:
> 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.
well, the RPATH entry was not designed to be patched, any other string
in an executable could be patched too:
const char* my_builddir_flag = "$$$$_I_M_NOT_INSTALLED_$$$$";
...
if (*my_builddir_flag)
{
... code when not installed
}
else
{
... code for the installed version
}
Just search for that string in the executable and replace the first byte
with a '\0'. Not sure there is a simple tool to do that, but writing one
shouldn't be hard.
Maybe it would even be accepted as an option into cmake.
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151201/33428c6d/attachment.html>
More information about the CMake
mailing list