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.
What problem does your feature solve?
The repository currently ships two separate binaries for generating code from XDR
.xfiles:xdr-generator-rust(inxdr-generator-rust/generator/) — producessrc/generated.rs.generator-definitions-json(inxdr-generator-rust/generator-definitions-json/) — producesxdr-definitions-json/xdr.json.Both are invoked internally by the
Makefileviacargo run --manifest-path …, and they sit in an inner workspace that isn't part of the top-levelstellar-xdrcrate. To use either of them a downstream consumer has to know about the inner workspace andcargo install --git … --bin …the specific binary they want, rather than reaching for thestellar-xdrCLI they already know.The
stellar-xdrCLI (behind theclifeature) already provides XDR-related commands (types,decode,encode,compare,xfile,generate— wheregenerateemits XDR values). Code generation from.xfiles 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-xdrCLI as new subcommands, so users get both code generators alongside the existing tools under the singlestellar-xdrbinary 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:
xdr-generator-rust/generatorandxdr-generator-rust/generator-definitions-jsoninto library crates (the bin targets can remain for internalmake generate, or be dropped entirely if the CLI is invoked from the Makefile instead).generate-rustandastsubcommands under the existingxfilemodule insrc/cli/, each calling into the relevant library.Makefileto invokecargo run --features cli -- xfile generate-rust …/xfile ast …in place of the current twocargo run --manifest-path …calls.What alternatives are there?
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.xinputs, and leaves the inner workspace visible to anyone who just wants to generate code.