You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the .yml files used by downstream projects contains the library_path field that contain an hardcoded location of the ruby script as it is in the build machine, see for example:
--- # Subcommands available inside ignition-transport.
format: 1.0.0
library_name: ignition-msgs
library_version: 1.0.0
library_path: E:/superinstaller/vcpkg/packages/ignition-msgs1_x64-windows/lib/ruby/ignition/cmdmsgs1
commands:
- msg : Print information about messages.
---
Ideally, ign-tools it should be able to encode the location of the ruby script relativly to the location of the .yml file.
Motivation
On a Windows system, it may occur that the installation location in the target system is different from the one of the build machine.
Describe alternatives you've considered
Always forcing users to install binary version of ignition libraries in the same prefix.
Alternativly, the .yml could provide some sort of "installation script" that would be run when installing them on a new machine, but in my experience such solution are more error-prone that a pure relocatable package.
Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).
Summary
Currently the
.yml
files used by downstream projects contains thelibrary_path
field that contain an hardcoded location of the ruby script as it is in the build machine, see for example:Ideally, ign-tools it should be able to encode the location of the ruby script relativly to the location of the
.yml
file.Motivation
On a Windows system, it may occur that the installation location in the target system is different from the one of the build machine.
Describe alternatives you've considered
Always forcing users to install binary version of ignition libraries in the same prefix.
Alternativly, the
.yml
could provide some sort of "installation script" that would be run when installing them on a new machine, but in my experience such solution are more error-prone that a pure relocatable package.Additional context
A nice description of the problem of the relocatable install (but in CMake context) can be found at https://cmake.org/cmake/help/v3.14/manual/cmake-packages.7.html#creating-relocatable-packages .
cc @seanyen-msft
The text was updated successfully, but these errors were encountered: