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.
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>
pkg-config was probed up to three times per build: once inside
generate_bindings for the header include paths, once for linking, and
then main unconditionally emitted `cargo:rustc-link-lib=vlc` on top of the
directives the successful probe already prints, libvlc ended up on
the link line two or three times.
Probe a single time in main and thread the resulting Library into
generate_bindings for its include paths. Drop the manual rustc-link-lib
line, since a successful pkg_config probe emits it.
binding.rs generation with bindgen is optional.
By default, a pre-generated binding.rs is copied in OUT_DIR. This allows
for example to build on Windows and link against a standard VLC
installation.
Feature "use-bindgen" will trigger binding generation.
Alaric Senat