Project Management (XRobot)
XRobot is the Module manager for LibXR. It fetches Modules, locks each one to a commit, and generates the main function XRobotMain from the YAML configurations under User/. The complete steps for creating and building a new BSP are in Quick Start.
Installation
Installing the pip package xrobot is described in Environment Setup. The version a BSP uses is recorded in the xrobot: field of Modules/modules.yaml; install the same version, for example pipx install xrobot==1.0.1. The VS Code extension XRobot.xrobot shows what xrobot describe reports and makes every change through an xrobot command; see VS Code Extension.
BSP Layout
The BSP root is the nearest directory containing Modules/modules.yaml. Every command works from any subdirectory of the BSP, or with -C DIR.
| File | Committed | Meaning |
|---|---|---|
Modules/modules.yaml | yes | Requested Modules (owner/Repo@ref) and the xrobot: tool pin |
Modules/sources.yaml | yes | Sources (index.yaml) and their priorities |
xrobot.lock | yes | Exact commit of every Module in the dependency closure |
*.yaml under User/ (subdirectories included) | yes | Configurations, each describing one product; User/libxr_config.yaml is not one |
Entry source under User/ | yes | Registers BSP objects with XR_REGISTER and calls XROBOT_MAIN() |
Modules/<owner>/<Repo>/ | no | Module checkouts at the locked commits |
Modules/CMakeLists.txt | no | Generated by xrobot setup |
User/xrobot_main.hpp | no | Generated header with the main function XRobotMain, for the selected configuration |
xrobot init creates Modules/modules.yaml, Modules/sources.yaml and User/xrobot.yaml in the current directory, adds the generated files to .gitignore, and writes .gitattributes (* text=auto, *.sh text eol=lf, *.bat text eol=crlf; an existing file only gets the lines it lacks). Text is stored with LF in the repository and converted on checkout, so regenerating the project with CubeMX on Windows or Linux produces only real changes in a commit.
Commands
| Command | Purpose |
|---|---|
xrobot --version | Print the installed xrobot version |
xrobot init | Create the BSP files in the current directory, with .gitignore and .gitattributes entries |
xrobot setup [--no-line-directives] | Resolve and lock Modules, check every config, regenerate User/xrobot_main.hpp |
xrobot gen [-c CONFIG] [--no-line-directives] | Generate User/xrobot_main.hpp (selects that configuration; --no-line-directives leaves out #line) |
xrobot describe [-c CONFIG] | Print the BSP state as JSON for editors |
xrobot sync [-c CONFIG]... | Add new fields/parameters with defaults, drop removed ones |
xrobot format [--check] [-c CONFIG]... | Rewrite configs in the canonical layout |
xrobot instance [-c CONFIG] add|set|remove|rename | Edit one instance |
xrobot module add|remove owner/Repo[@ref] | Edit Modules/modules.yaml |
xrobot module show MODULE | Print a Module's manifest and constructors (folder, header or Module id) |
xrobot new-module NAME | Create a Module skeleton (header, CMake, README, CI) |
xrobot check-module MODULE | Resolve Modules as setup does (updates xrobot.lock and Modules/), then write the constructor call that Module CI compiles (compiled, never executed) |
xrobot source ... | Query or edit Sources |
xrobot <command> --help lists each command's options.
Command output and errors follow the system language: Chinese in a Chinese environment, English otherwise. The environment variable XR_LANG selects the language (zh or en); the LibXR_CppCodeGenerator commands use the same variable. Generated files do not change with the language.
In This Chapter
- Module Requests and the Lock:
modules.yaml, ref rules,xrobot.lock,xrobot setupand the release gate - Configuration: format, dependency binding, structs, constants, several configurations
- Main Function Generation:
XR_REGISTER,XROBOT_MAIN(), the generated header and the build check - Writing a Module: Module class and constructor, manifest
- Sources:
sources.yaml,index.yamlandxrobot source - CI and Firmware Release: Module CI, STM32 BSP CI and firmware release