We are trying to get the bindings build with a single committed
source file compiled on every target. Assertions are per-host and would
break on different architecture than the commiter's one. Layout checks
notably break the 32bit targets.
Windows has no import library to link against: the VLC installer and
.zip ship libvlc.dll but no .lib. Previous workaround was to use vswhom
+ dumpbin + lib.exe to synthesise one at build time from the DLL's
exports.
rustc's `raw-dylib` linkage removes the need entirely, it generates the
imports straight from the DLL name.
vsnprintf is a C-runtime symbol, not a libvlc export, so it has no business
sitting in the block of bindings generated from libvlc's headers. It only
ended up there because the Windows link workaround needed a declaration.
Drop it from the allowlist and declare it by hand in lib.rs.
libvlc only ever takes a FILE by pointer on the log callback, but bindgen
emitted glibc's concrete _IO_FILE along with a layout assert baking in the
host's field offsets. That assert fails on MSVC and forces new bindings
generation specific for it.
Blocklisting the type and re-exporting libc's FILE, which is opaque
works around the issue.
bindgen defaults to one `extern "C"` block per function, which gives 315
blocks for a header set that binds a single library. Ask for a merged one
instead.
bindgen spells the log callback's va_list parameter the way the host
that ran it does. The bindings are generated once and compiled
everywhere, so that spelling only happens to be right on the generating
host.
This was alright for most hosts but is fragile on aarch64 where va_list
is a plain 32 bytes struct.
Given we only forward the list to vsnprintf, extracting and simplifying
the cross-platform rust implementation from the unstable std-lib is
cheap and sound. We will just have to re-export the official type once
it's stablilized.
bindgen's output is a committed source file, so the version producing it
has to be pinned like any other input. With `bindgen = "0.72"` floating,
a patch release that changes formatting silently changes the generated
bindings.
`--locked` on the alias keeps cargo from quietly updating it when the
manifest disagrees.
Generating the FFI bindings at consumer build time is unecessary. The
`use-bindgen` Cargo feature was non-additive, and forced bindgen +
libclang onto every build that opted in, for a decision that is really
about the maintainer's environment, not the public API.
Move binding generation out of the build entirely, following the xtask
pattern[^1]:
- build.rs is reduced to locating and linking libvlc.
- Regeneration lives in a `xtask` crate, run with `cargo xtask bindgen`.
[^1]: <https://github.com/matklad/cargo-xtask>
Alaric Senat