lumeohq/onvif-rs

notes on code generation

scottlamb opened this issue · 3 comments

scottlamb commented

(Context: I'm testing a yaserde replacement as mentioned here. Not only is ONVIF my ultimate goal, but onvif-rs is also large enough to be a good testbed for comparing compile times and generated code sizes. My replacement isn't quite drop-in, so I made changes to xsd-parser-rs.)

Are there any notes on how to regenerate the schema/src files? I couldn't find any. Here's my guess:

  1. Look over schema/src/lib.rs, which says which files are based on xsd or wsdl.
  2. Run a script like this:
#!/bin/bash -e

# Note that while there's a ws-discovery.xsd and a ws-discovery.wsdl,
# wsdl-parser fails on the latter, and ws_discovery.rs appears to be
# hand-written.

for input in xsd{,_external}/*.xsd; do
    base="$(basename "${input}" .xsd | sed -e 's/-/_/g')"
    if [[ "$base" = "ws_discovery" ]]; then
        echo "skipping $base xsd"
        continue
    fi
    echo "$base from xsd"
    ./xsd-parser --input "${input}" --output "schema/src/${base}.rs"
done

# This skips ws-discovery.wsdl, which doesn't have the extra .xml suffix.
for input in wsdl/*.wsdl.xml; do
    base="$(basename "${input}" .wsdl.xml | sed -e 's/-/_/g')"
    echo "$base from wsdl"
    ./wsdl-parser --input "${input}" --output "schema/src/${base}.rs"
done
  1. cargo fmt?
  2. Review diffs. Most/all files appear to start with manually added use blocks. Some (e.g. types.rs) appear to have other manually added code.
DmitrySamoylov commented

Hi, @scottlamb

I'm testing a yaserde replacement

Nice, do you have a public repo with your changes to yaserde or fork?

Are there any notes on how to regenerate the schema/src files?

No, we don't have a strict process yet, but your guess is close enough to how we generate it. Some XSD features are not supported right now by xsd-parser-rs, so in some cases, we do manual changes to the generated code (types.rs) and some modules are written manually from scratch (ws_discovery.rs). In all cases, we do imports manually.

cargo fmt?

Yes, we do that after the codegen.

As the 5th step, I'd also added cargo test because there are some manual workarounds to yaserde issues.

scottlamb commented

Thanks!

Nice, do you have a public repo with your changes to yaserde or fork?

I hope to make a public repo this week, after refining the interface a bit more and starting the docs. Strictly speaking, it's not a change to/fork of yaserde; instead it's a from-scratch implementation inspired by yaserde with similar derive macros.

  • 👍1