search

ros-tooling / cross_compile

A tool to build ROS and ROS2 workspaces for various targets
Apache License 2.0
186 stars 58 forks source link

Support workspace overlaying #299

Open TSC21 opened 3 years ago

TSC21 commented 3 years ago

Description

This is not a bug but rather a question (it might end-up being a feature request, but not sure): I have a package A which requires a package B. I don't want to include both packages in the same colcon workspace because they will end-up being both being built and installed under the same environment rules (i.e., same install folder), and for practical purposes this is not what is pretended, since I already install package B in a underlay workspace.

What I have tried so far was to pick up the install folder from the package B underlay workspace, install it using the custom-setup-script option by copying it to a specific folder and adding echo "source /underlay_ws/setup.bash" >> ~/.bashrc, but when it reaches the stage of building the workspace, it doesn't find the package (with find_package(B REQUIRED)). This also means I can't add the package B as a dependency of package A in its package.xml because rosdep fails to find the package (which is normal since the package isn't fetchable by rosdep).

What should be the approach here? I mean one can always add both package into the same workspace, and then build them with ros_cross_compile, but what would be the consequence of deleting the generated output install folder for package B after the build process finishes, so one would only deploy the install folder for package A? Would the package B still work if a runtime dependency on package A exists but from an underlay workspace instead of the same workspace?

@emersonknapp thanks in advance for any help finding a solution for the above!

System (please complete the following information)

TSC21 commented 3 years ago

What should be the approach here? I mean one can always add both package into the same workspace, and then build them with ros_cross_compile, but what would be the consequence of deleting the generated output install folder for package B after the build process finishes, so one would only deploy the install folder for package A? Would the package B still work if a runtime dependency on package A exists but from an underlay workspace instead of the same workspace?

OK I have the answer for this already: it does work if I delete the package B resulting install folder/env and source the underlay workspace install with the package B in it, and then source the resulting install_<arch> from the ros_cross_compile. Though this is not ideal (because it forces us to build the same package, where this could be sourced first so to be found by the colcon build on the workspace build stage), this approach works.

emersonknapp commented 3 years ago

If I understand correctly - this is a feature request to support overlay workspaces. Is that correct? If so, I think we can re-write this ticket as such, there isn't support for it yet.

TSC21 commented 3 years ago

If I understand correctly - this is a feature request to support overlay workspaces. Is that correct? If so, I think we can re-write this ticket as such, there isn't support for it yet.

Well yes we can say it like that. We want to cross compile with dependencies on underlay workspaces (so yes the workspace built with ros_cross_compile will be an overlay).