Feature/cpack pinocchio sticky rpath

[kvasios]

Recommendation for maintaining the rpath in libfranka.so after system installation with cpack. This makes handling pinocchio as a secondary dependency easier when building against libfranka.so.

[kmohyeldine]

Thanks for this, and apologies it sat here so long.

This still merges cleanly, but the problem it solves no longer exists, so we're going to close it.

When you opened this, pinocchio was a shared library that CI built from source (v2.7.0) and that the devcontainer pulled in via robotpkg-pinocchio, which installs under /opt/openrobots/lib. Neither location is on the default loader search path, so a cpack-installed libfranka.so genuinely could not resolve libpinocchio.so at runtime. Baking the rpath in was the right call at the time.

Since the Dockerfile consolidation, .ci/Dockerfile builds pinocchio v3.4.0 with -DBUILD_SHARED_LIBS=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_LIBDIR=/usr/lib. Pinocchio is now statically linked into libfranka.so, so there is no shared object left for an rpath to point at. Even in a shared build, the heuristic here would resolve /usr/lib/cmake/pinocchio up two directories to /usr/lib, which the loader already searches. Either way the property would be a no-op today. That's consistent with the packaging, where CPACK_DEBIAN_PACKAGE_DEPENDS carries no pinocchio runtime dependency.

If we ever go back to linking pinocchio dynamically, we'll want a slightly different shape than this: deriving the path from pinocchio_DIR bakes the build machine's prefix into a .deb that gets installed elsewhere, and the two-level get_filename_component walk assumes a lib/cmake/pinocchio layout that doesn't hold for share/cmake/pinocchio installs. CMAKE_INSTALL_RPATH_USE_LINK_PATH, or a proper Debian dependency, would be the way to go.

Appreciate you taking the time to send this upstream.