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

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to