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

Johannes Zarl-Zierl johannes.zarl-zierl at jku.at
Thu Dec 3 04:59:26 EST 2015


> > I.e. it could be replaced with a string of the same length or a
> > shorter one, but not a longer one.
> > 
> > CMake works around this by extending the build RPATH artificially with
> > ":" at the end I think, patchelf works around this by making the whole
> > executable one page bigger if the new entry is longer.
> 
> Just an implementation notes, doesn't change the fact that it can be
> done and it's designed to be modifiable.

This is only nitpicking about a side-topic, but: Just because it can be done 
does not mean that it was designed for that purpose.
You argument is like saying that a wrench was designed to be used as a hammer 
(after all, you can hit a nail with it).

If one were to follow that argument, it would be very hard *not* to design 
something for a given purpose.

> > 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.

If RPATH were *designed* to be modifiable, it would need provisions to account 
for arbitrary path lengths.
One possible solution (not necessarily the best, or even a good one) would be 
to make RPATH a fixed-length field, part of which is a pointer to the next 
entry, if any.

Regards,
  Johannes


More information about the CMake mailing list