[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