Skip to content

Embed the rust generator and definitions-json generator into the stellar-xdr CLI #527

Description

@leighmcculloch

What problem does your feature solve?

The repository currently ships two separate binaries for generating code from XDR .x files:

  • xdr-generator-rust (in xdr-generator-rust/generator/) — produces src/generated.rs.
  • generator-definitions-json (in xdr-generator-rust/generator-definitions-json/) — produces xdr-definitions-json/xdr.json.

Both are invoked internally by the Makefile via cargo run --manifest-path …, and they sit in an inner workspace that isn't part of the top-level stellar-xdr crate. To use either of them a downstream consumer has to know about the inner workspace and cargo install --git … --bin … the specific binary they want, rather than reaching for the stellar-xdr CLI they already know.

The stellar-xdr CLI (behind the cli feature) already provides XDR-related commands (types, decode, encode, compare, xfile, generate — where generate emits XDR values). Code generation from .x files is a natural fit for the same CLI surface but is currently excluded from it.

What would you like to see?

Embed both generators into the stellar-xdr CLI as new subcommands, so users get both code generators alongside the existing tools under the single stellar-xdr binary they already know.

Suggested shape (names open to discussion):

  • stellar-xdr xfile generate-rust --input xdr/*.x --output src/generated.rs …
  • stellar-xdr xfile ast --input xdr/*.x --output xdr.json [--feature …]

Under the hood:

  • Convert xdr-generator-rust/generator and xdr-generator-rust/generator-definitions-json into library crates (the bin targets can remain for internal make generate, or be dropped entirely if the CLI is invoked from the Makefile instead).
  • Add generate-rust and ast subcommands under the existing xfile module in src/cli/, each calling into the relevant library.
  • Update the Makefile to invoke cargo run --features cli -- xfile generate-rust … / xfile ast … in place of the current two cargo run --manifest-path … calls.

What alternatives are there?

  • Keep the standalone bins as-is — users can already cargo install --git … --bin xdr-generator-rust (or the definitions-json bin), but this fragments the surface across three separate CLIs that all operate on the same .x inputs, and leaves the inner workspace visible to anyone who just wants to generate code.
  • Expose only one of the two generators via the CLI — e.g. embed just the Rust generator. Leaves the JSON AST generator still behind a separate bin and keeps the workspace split.
  • Do nothing — the current setup works for in-repo regeneration; downstream users just have a more obscure path to the tooling.

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions