REP-2001: Propose c++-only minimal ros2 variant #231
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,15 +33,63 @@ Specification | |
| End-user entry points | ||
| --------------------- | ||
|
|
||
| We define these main entry points for ROS users. | ||
|
|
||
| * desktop (recommended) | ||
| * ros_base | ||
| * ros_core | ||
| * ros_cpp_core (advanced) | ||
|
|
||
| Variants | ||
| -------- | ||
|
|
||
| ROS C++ Core | ||
| ''''''''''' | ||
|
|
||
| The `ros_cpp_core` variant is a restricted subset of `ros_core` functionality with support for only C and C++. | ||
| It targets resource- and tool-constrained environments where package managers may be limited or unavailable. | ||
| The intention is that this variant can target cross-compiling for custom OS sysroots that may not have build tools or Python available that run on the target platform. | ||
|
There was a problem hiding this comment. If it is an explicit goal for this variant to be able to be used on a target system that doesn't have Python available, a different building + environment setup process should be highlighted as the currently recommended one (colcon build + source a setup file) does not fulfill this requirement (colcon/colcon-core#73) There was a problem hiding this comment. The goal isn't to have this be built on a target system that doesn't have Python available. The intention is to be built for a target system that doesn't have Python available. I want to make a strong distinction between the build-time environment and the run-time environment. While these are often the same in classic ROS workflows, It shouldn't be the assumption. Do you think I should add language around that here? I fully expect this to be built with colcon and linted with cpplint, for example. There was a problem hiding this comment. The build also needs Python to run the code generators for messages / services / actions. There was a problem hiding this comment. But that's not needed at runtime, right? There was a problem hiding this comment.
That's what I meant as well but it was not clear. There was a problem hiding this comment. Oh - I see what you mean. The way I have used it is to
Now that I'm thinking about that, yes, it seems we'll need a non-python way to set up the proper environment variables. Would it be possible to get away with creating a fairly simple pure-shell utiility? Something that would
There was a problem hiding this comment. That simple approach will only work for a subset. A complete shell-based solution must replicate the same logic as it is implemented in Python. That includes collecting all packages in the prefix, getting their dependencies (available in the filesystem, doesn't need to parse the manifests), order them topologically, and then source the setup files of each package. If the shell-based solution doesn't implement the logic around There was a problem hiding this comment. Are these details just necessary to handle the different types of installs, or is it deeper than that? Perhaps we could impose limitations on the usage of this variant so as to avoid more complexity in the environment setup.
Do these require python, or just the top level script does? There was a problem hiding this comment.
That has nothing do to with the different types of installs. The importance is the order. One package might rely on an environment change caused by another package it depends on.
No, they don't. |
||
| Build tools may use Python, this variant is not intended to restrict build tooling. | ||
| It may not contain any GUI or Python dependencies. | ||
| It may not have any dependencies outside a source workspace of its members. | ||
| Note that this variant chooses an RMW and rcl_logging implementation based on their minimal dependency footprint. | ||
|
|
||
| :: | ||
|
|
||
| - ros_cpp_core: | ||
| # These are the packages we are actually targeting | ||
| packages_up_to: [rclcpp, rclcpp_action, rclcpp_lifecycle, rclcpp_components] | ||
| # This is the full package set that is actually built, and needs to meet above specified dependency criteria | ||
| packages_all: [ | ||
| action_msgs, ament_cmake, ament_cmake_core, | ||
| ament_cmake_export_definitions, ament_cmake_export_dependencies, | ||
| ament_cmake_export_include_directories, | ||
| ament_cmake_export_interfaces, ament_cmake_export_libraries, | ||
| ament_cmake_export_link_flags, ament_cmake_gmock, | ||
| ament_cmake_gtest, ament_cmake_include_directories, | ||
| ament_cmake_libraries, ament_cmake_pytest, ament_cmake_python, | ||
| ament_cmake_ros, ament_cmake_target_dependencies, ament_cmake_test, | ||
| ament_cmake_version, ament_index_cpp, ament_index_python, | ||
| ament_package, builtin_interfaces, class_loader, | ||
| composition_interfaces, console_bridge_vendor, cyclonedds, | ||
| cyclonedds_cmake_module, domain_coordinator, libyaml_vendor, | ||
dirk-thomas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| lifecycle_msgs, poco_vendor, rcl, rcl_action, rclcpp, | ||
| rclcpp_action, rclcpp_components, rclcpp_lifecycle, | ||
| rcl_interfaces, rcl_lifecycle, rcl_logging_noop, | ||
| rcl_logging_spdlog, rcl_yaml_param_parser, rcpputils, rcutils, rmw, | ||
| rmw_cyclonedds_cpp, rmw_implementation, rmw_implementation_cmake, | ||
| rosgraph_msgs, rosidl_adapter, rosidl_cmake, | ||
| rosidl_default_generators, rosidl_default_runtime, | ||
| rosidl_generator_c, rosidl_generator_cpp, rosidl_parser, | ||
| rosidl_typesupport_c, rosidl_typesupport_cpp, | ||
| rosidl_typesupport_interface, rosidl_typesupport_introspection_c, | ||
| rosidl_typesupport_introspection_cpp, spdlog_vendor, | ||
| test_interface_files, test_msgs, tinydir_vendor, tracetools, | ||
| unique_identifier_msgs] | ||
| # These can't be built without external dependencies and are not desired, but they end up in the source workspace and need a COLCON_IGNORE file | ||
| packages_ignore: [rcl_logging_log4cxx] | ||
|
|
||
|
|
||
| ROS Core | ||
| '''''''' | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somewhat pedantic, but with
ros_core, I thinkros_core_cppwould follow the naming convention we generally use (see all packages below).Also the "advanced" tag is a little unclear (what's advanced about it? Isn't it more basic than
ros_core? etc). I might change it tobarebonesif you'd like to include some qualifier, which I'm not sure is necessary. The name itself is very telling.