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

[Ruslan Baratov]

On 04-Dec-15 03:47, Alexander Neundorf wrote:
>
> On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote:
>
> > On 03-Dec-15 04:34, Alexander Neundorf wrote:
>
> > > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
>
> > > If RPATH was _designed_ to be patchable, tools could just do it,
>
> > > instead of having to implement workarounds for longer strings. E.g.
>
> > > the linker would support a command line argument how much space it
>
> > > should reserve for the RPATH entry, or something like that.
>
> >
>
> > I think it's not possible. As far as I know there is no limitation for
>
> > path size on Linux for example. Hence it's not possible to predict what
>
> > size for path to library user want to use by setting RPATH.
>
> More nitpicking about the meaning of "designed" ;-) :
>
> CMake knows the length of the build RPATH and the length of the 
> install RPATH. Let's say the build RPATH has a length of 100, and the 
> install RPATH has a length of 150, it could, during linking, give the 
> build RPATH to the linker, and also something like --rpath-size=150, 
> and the linker would make the field for the RPATH 150 bytes big, so it 
> could be patched easly later on.
>
> This is what I would consider the minimum support if it was "designed" 
> to be patched.
>
> Instead cmake has to add 50 ":" at the end of the build RPATH. :-/
>
> ...
>
> > > The idea above was only for solving the question "am I installed ?"
>
> > > yes/no, not "where am I installed ?".
>
> >
>
> > Then I don't understand how it's planned to be used. I thought that in
>
> > build directory you changing "$$$$_I_M_NOT_INSTALLED_$$$$" to
>
> > "/path/to/build/directory" so resources can be found there, and on
>
> > install you change it to "/path/to/install/directory". So my guess is
>
> > not correct?
>
> Nothing is planned, just some ideas.
>
> The idea was, during install, to set the first byte of that special 
> string to '\0', and in the code you test whether the string is empty ( 
> -> it has been patched, so it is installed) or not (still the original 
> "$$$$_I_M_NOT_INSTALLED_$$$$").
>
> With that information, the developer can then do whatever he wants. 
> e.g. when not installed, search just in $CMAKE_BINARY_DIR (which could 
> be configured into some other string), and if installed, search in 
> some other way.
>
Will not work, just like I said compiler is smart enough to figure out 
if the first char in string literal is '\0' or not. Just make some 
testing: https://gist.github.com/ruslo/04d8993800ee78513d1c

The only one possibility to implement what you want I see in creating 
new dynamic library (probably by CMake) with one literal:

// 3rd party library API
const char* path_to_install();

void parse_resources() {
   const char* x = path_to_install();
   assert(x != 0);
   if (x[0] == '\0') {
     // OK, can't be optimized since it's an external library
   }
   else {
     // load resources
   }
}

So CMake should create such library in build directory and then 
re-create and install it with new string in install directory. Of course 
if you move such library it will not work :) So still doesn't make sense 
to me...

Ruslo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151204/54455e73/attachment-0001.html>