vlcrs_plugin exposes the base types to create plugin, much like
vlc_plugin.h in the C headers, and uses the vlcrs_core::object::Object
type. But vlcrs_core also needs vlcrs_plugin internally to define the
capabilities, and both need each other for tests also.
The same applies to vlcrs_macros when used in tests, which must stay
separated, but we can still provide it as a dev-dependencies and avoid
the cyclic reference.
Otherwise, stale files in any src/rust/vlcrs-*/ folder makes the folder
alive without manifest or with a non-complete manifest and everything
breaks...
The vlcrs-plugin crate exports structures matching vlc_plugin.h, which
is ough to be included by modules directly or indirectly (through
vlcrs-macros) to define every parts needed to setup the module manifest.
The current state exports a minimal set required for the current
vlcrs-macro code to work correctly.
Expose the version and license keys to every members of the workspace.
The rationale is that every core crates merged into `src/rust/` will
be versioned under the same revision as the core.
This binary crate, called vlcrs-sys-generator, uses the bindgen[1] crate
to automatically generate raw (extern "C"...) bindings, which are then
used by safe abstractions.
The goal is for this program to be used to generate raw bindings that
are which will be used by safe abstractions, each safely wrapping a part
of the VLC core API, generally a header will be a crate. This is done so
that the so that the dependency chain of the Rust modules closely
follows that of the C modules, in particular a demux module should not
need to be rebuild if it doesn't depend on vout.
Since writing and maintaining raw bindings is tedious and error-prone,
the raw bindings (extern "C"...) are generated using a Clang front-end,
bindgen, written in Rust. Updating the bindings should be as simple as
running `cargo run -p vlcrs-sys-generator'.
[1]: https://rust-lang.github.io/rust-bindgen/