Background
The build system uses SWIG's -xml output to extract struct field information from Payload.h headers, which is then consumed by generateSWIGModules.py to emit RECORDER_PROPERTY_ macros. This works for the basic case but has limitations: SWIG XML is an internal implementation detail not designed for downstream consumption, it doesn't reliably carry C-level type metadata (field sizes, alignment, padding, enum values, doc comments), and the format is brittle to SWIG version changes.
Proposed solution
Replace the SWIG XML step with a libclang-based parser that directly inspects each *Payload.h header and emits a structured JSON description of the payload struct. This JSON becomes the single source of truth for generateSWIGModules.py when generating RECORDER_PROPERTY_* macros, producing at least the same output as today, but with more accurate C-level type information (exact sizes, enum integer values, array shapes, alignment/padding).
The richer metadata also opens the door to additional code generation that was not feasible with SWIG XML, such as generating typed Python constructors with accurate field signatures and docstrings sourced from the header comments.
Background
The build system uses SWIG's -xml output to extract struct field information from Payload.h headers, which is then consumed by generateSWIGModules.py to emit RECORDER_PROPERTY_ macros. This works for the basic case but has limitations: SWIG XML is an internal implementation detail not designed for downstream consumption, it doesn't reliably carry C-level type metadata (field sizes, alignment, padding, enum values, doc comments), and the format is brittle to SWIG version changes.
Proposed solution
Replace the SWIG XML step with a libclang-based parser that directly inspects each
*Payload.hheader and emits a structured JSON description of the payload struct. This JSON becomes the single source of truth for generateSWIGModules.py when generatingRECORDER_PROPERTY_*macros, producing at least the same output as today, but with more accurate C-level type information (exact sizes, enum integer values, array shapes, alignment/padding).The richer metadata also opens the door to additional code generation that was not feasible with SWIG XML, such as generating typed Python constructors with accurate field signatures and docstrings sourced from the header comments.