Schema-driven YAML configuration parser and config type definitions for
ros_portal.
The JSON schema is the source of truth for the C++ config structs used by
ROS Portal. RosPortalConfig, its nested structs, enums, and parser are
generated from schema/ros_portal_config.schema.json; the main ROS Portal package depends
on this package and consumes those generated types directly.
schema/ros_portal_config.schema.json: source of truth for the YAML config structure and the generated C++ structs used by ROS Portal.scripts/generate_config_parser.py: reads the schema and builds a small model of the config types, fields, enums, and parser functions.scripts/templates/config_parser.hpp.j2: Jinja2 template for the public C++ API consumed by ROS Portal, includingRosPortalConfig, nested config structs, enums, andConfigParser.scripts/templates/config_parser.cpp.j2: Jinja2 template for the parser implementation and schema-specific validation logic.include/ros_portal_config/config/error.hpp: public exception type thrown when config parsing or validation fails.src/config/utils.hppandsrc/config/utils.cpp: schema-agnostic YAML helpers used by the generated parser.test/: unit tests for generated parser behavior and the shared YAML utilities.
CMake runs scripts/generate_config_parser.py during the build. The generator
loads schema/ros_portal_config.schema.json, renders the .hpp.j2 and
.cpp.j2 templates, and writes generated files under the build directory:
generated/config_parser/include/ros_portal_config/config/config_parser.hppgenerated/config_parser/src/config/config_parser.cpp
The generated header is installed with the package, so downstream code includes:
#include "ros_portal_config/config/config_parser.hpp"When adding or changing config fields, update the JSON schema first. The structs used by ROS Portal and the parser validation code are regenerated from that schema on the next build. Template changes should only be needed when changing the generated C++ shape or supporting a new schema feature.
src/config/utils.hpp and src/config/utils.cpp keep reusable yaml-cpp
validation helpers out of the generated code. They handle common operations such
as:
- building readable field paths like
$.ros_portal.topics - adding line and column context to errors
- checking map and sequence nodes
- converting scalar values
- rejecting unknown fields
These helpers do not know about RosPortalConfig; schema-specific behavior
belongs in the generator and templates.
config_parser_test verifies the generated parser against representative YAML
inputs. config_utils_test covers the schema-independent YAML helper behavior.