Repository navigation
build: check in the generated bindings and drop the build script - #8
Conversation
The bindings are generated once from the vendored libva headers by `just bindgen` and checked in, so building the crate needs neither bindgen nor libclang. `just ci` regenerates them and fails on a difference. libva pads `VAProcPipelineCaps` and `VAProcPipelineParameterBuffer` by pointer width, so the recipe generates for x86_64 and i686 and merges the two under a `cfg` on those fields. Any other difference between the two fails the recipe. The `libva_1_X_or_higher` cfgs go with the build script: the headers are pinned at libva 2.23, so every gated item was always compiled in. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Wire moq-video's VAAPI backends to the moq-vaapi changes in moq-dev/vaapi#8 through #11: H.265 Main encode and decode beside H.264, Surface::resize through the processor's pooled output surfaces, and checked-in libva bindings. With no bindgen left, `vaapi` is on by default in moq-video, moq-transcode, and moq-cli, and moq-c's Nix build drops its bindgen hook. Needs the moq-vaapi release carrying those PRs; the workspace bump follows it. The quest is rewritten to that remaining work. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
WalkthroughThe crate now includes checked-in VA-API bindings generated from vendored headers. The justfile provides binding-generation and drift-check recipes, and the vendor recipe regenerates bindings after refreshing headers. The build script and shared bindgen builder are removed. Several buffer and surface fields, variants, and handling paths no longer use libva-version compile-time gates. Pre-merge checks:
|
Part of the moq-video VAAPI quest, moq-dev/moq#8013: the
vaapifeature should cost nothing at build time so moq-video can turn it back on by default.Problem
Building moq-vaapi runs bindgen from
build.rs, which needs libclang on the build machine. Every crate that depends on moq-video withvaapion inherits that, which is why moq-video ships it off by default.Approach
just bindgengeneratessrc/bindings/libva.rsfrom the vendored libva 2.23 headers, and the file is checked in.build.rs,bindgen_gen.rs, and thebindgen/regexbuild dependencies are gone. This matches how moq-nvenc and moq-v4l carry their bindings.VAProcPipelineCapsandVAProcPipelineParameterBufferby pointer width (__x86_64__ || __LP64__). The recipe generates forx86_64-unknown-linux-gnuandi686-unknown-linux-gnu, then merges the two: lines they share go in as they are, and the differingva_reservedlines go undercfg(any(target_arch = "x86_64", all(target_pointer_width = "64", not(windows))))and its negation. Any other difference fails the recipe, so a header bump that adds more width-dependent layout cannot slip through.just ciregenerates the bindings and fails on a diff, so the checked-in file stays what the headers produce.just vendorregenerates them after refreshing the headers.libva_1_X_or_highercfgs came from the build script reading the header version. The headers are pinned at 2.23, so every gated item was always compiled; the gates are removed.clangforrust-bindgen(bindgen-cli 0.72.1) and dropsLIBCLANG_PATH.Impact
libva/andlibva-wrapper.h, which only the recipe reads.*_rawbitfield accessors and theraw_get/raw_sethelpers on bitfield units, which are additive.Validation
nix develop --command just cipasses, including the regeneration check.Alternatives
va_reservedhand-patched: silently wrong if a later header adds another width-dependent field, which the two-target diff catches.Review
Codex (
quest review), one round: no findings.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code