robotology/ycm — pull request #76 by francesco-romano (2014-12-01 14:24:53+00:00)
Title: Add RPATH macro

I'm (still) working on creating an RPATH macro.

There are still some issues opened, but maybe @drdanz can help me fix them.

1) Currently the first argument is only needed to create the option. I don't understand how I can use the `CMakeDependentOption` and the `CMakePackageConfigHelpers` to correctly parse the options.

2) Currently this macro enables by default RPATH. Honestly I don't see any disadvantage of enabling RPATH w.r.t. the old way (i.e. libraries and bins with completely wrong search paths). Different is the case if one wants to enable e full-name installation. Disabling the macro does not lead to full-name installation, but simply revert to cmake default (and incomplete) RPATH configuration. At least, this is what I understood so far.

3) This is an important point:
The variable `CMAKE_INSTALL_RPATH_USE_LINK_PATH` simply automatically adds all the library search paths to the install rpath variable. This is handy but can lead to some problem.
I try to explain better:
Let's consider a gazebo-yarp plugin. It links to gazebo (default search path) and yarp (custom installation, but in my case it will reside at the same location of the plugin lib).
If I set the `CMAKE_INSTALL_RPATH_USE_LINK_PATH` variable the resultant LC_RPATH will be
```bash
$ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)
--
cmd LC_RPATH
cmdsize 48
path /usr/local/Cellar/gazebo4/4.0.0/lib (offset 12)
--
cmd LC_RPATH
cmdsize 72
path /usr/local/Cellar/gazebo4/4.0.0/lib/gazebo-4.0/plugins (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /usr/local/Cellar/sdformat/2.0.1/lib (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /usr/local/Cellar/protobuf/2.5.0/lib (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /Users/makaveli/Projects/src/local/lib (offset 12)

otool -L libgazebo_yarp_controlboard.dylib
libgazebo_yarp_controlboard.dylib:
@rpath/libgazebo_yarp_controlboard.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libgazebo_yarp_singleton.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libYARP_OS.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_sig.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_math.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_dev.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_name.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_init.1.dylib (compatibility version 1.0.0, current version 2.3.63)
/usr/local/lib/libgazebo_transport.4.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/lib/libgazebo_physics.4.dylib (compatibility version 4.0.0, current version 4.0.0)
.....
```

The only useful line is the first one (`@loader_path/`). All the others are useless because they refer to either full-name libraries (gazebo) or to yarp which is already "resolved" through `@loader_path`.

If instead I disable the variable the result is the following:
```bash
$ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)
```

Of course this is more clean, but it requires the cmake developer to know all the paths of the installed dependent (shared) variables.

4) the bin or lib variable is not strictly correct: maybe I should change it to `target_dirs` and `lib_dirs`.