-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ros2 run and ros2 pkg executables do not look for runtime executables in standard CMake GNUInstallDirs location #845
Comments
For better or worse, this is by choice and by design. First, let me address the use of the Second, we made these decisions back in 2017 or 2018 on where to store the binaries. So my memory is somewhat fuzzy. But as I recall, there is a very major reason for our current setup: Because ROS 2 is highly federated, it is very possible (and maybe even common) for multiple packages to create the exact same named binary. In our current If we were to put them all in @ros2/team that's my (5 year old) recollection of why we made this decision; is there anything else I'm missing? In order to make any changes here, we'd have to come up with an alternative way to avoid that particular problem. |
I'd be happy to entertain the idea of installing runtime program binaries (nodes) to This could be more clear to developers writing the CMake code than the current method. |
I remember the same thing.
IIRC part of the discussion was a decision that the executables aren't meant to be run directly by the user. They are meant to be run by another program like
It looks like both are allowed:
|
We can't exactly do that, anyway. Due to another problem with overlays, we also need to install headers to |
Fair enough. What about constraining any changes to allow installing nodes in |
Given what @sloretz posted above, I'm not really inclined to make the change at this time. That is, it doesn't seem any more "correct" than |
It also doesn't help the ament_cmake docs tell you to install your nodes in the wrong path. It says to set the runtime destination for binaries to install(TARGETS my_node
DESTINATION lib/${PROJECT_NAME}) Turtlesim, used in the tutorials, has this code, where it install the targets directly instead of using the export set. install(TARGETS turtlesim_node turtle_teleop_key draw_square mimic
DESTINATION lib/${PROJECT_NAME}) |
Oof, yeah, good call. That should really be corrected; I'll open a PR to do that.
Can you explain more about what you think the problem there is? As far as I can tell that is installing things like we expect. |
I can do the work, no worries. I'll tag you when it's fixed, there's much cleaner ways such as using an export set to do the install. |
Bug report
Required Info:
ros-humble-ros2cli/jammy,now 0.18.7-1jammy.20230721.205747 amd64
Steps to reproduce issue
Create a ROS package, and perform the install like so using modern CMake with GNUInstallDirs
Expected behavior
A call to
ros2 executables list PROJECT_NAME
should show PROJECT_NAME_node above which resides ininstall/PROJECT_NAME/bin/PROJECT_NAME_node
Actual behavior
A call to
ros2 executables list PROJECT_NAME
does not show a nodeAdditional information
According to the GNU directory standard:
The directory for installing executable programs that users can run. This should normally be /usr/local/bin
. ROS does not look here for nodes.My ROS answers post from a while ago
CMake GnuInstallDirs
Deep CMake for library authors slide 107
The actual cause for
ros2 pkg executables
is here:ros2cli/ros2pkg/ros2pkg/api/__init__.py
Line 44 in 4523cc5
The cause for people using the wrong directory is
ros2 pkg create
also puts them in the wrong place:ros2cli/ros2pkg/ros2pkg/resource/cmake/CMakeLists.txt.em
Line 90 in 4523cc5
Here is the relevant screenshot from docs:
The text was updated successfully, but these errors were encountered: