The `links` annotation in `Cargo.toml` is intended to ensure that in the
crate graph there's at most one crate that's an implementation of
some sort concept.
This can make sense in some scenarios, most prominent of which is when
the crate defines `#[no_mangle]` symbols (e.g. by compiling a vendored C
library.) In that situation linking a binary that depends on two
versions of the library cannot work because of colliding symbol names.
There does not appear to be a similar reason to impose such a
restriction on the users of `gstreamer-sys` and similar, however. All of
these crates link to a system library, they do not define any
`#[no_mangle]` symbols nor they vendor and build C libraries as part of
their build process. All they do is linking to a system library. Most
likely all the different versions of the bindings will link to the exact
same library too.
I haven't seen any global resources that these bindings use to ensure
soundness of the library, either.
Now that the crates are generated and linked against v1_20 binaries
there is no need to guard this codepath when building `dox` (which
inherently enables `v1_20` but did previously not actually compile
against that version yet).
Gir now uses analyzed objects to generate documentation, and to know
exactly what is available. Additionally, this allows more bindings to
be generated.
This version adds a `--strip-docs` flag to `generator.py`, used in
conjunction with `--strip-docs --embed-docs` to clean documentation
first before re-embedding it (otherwise the same text would show up
multiple times). It is also used in the CI to check that no
documentation disappears on stripping, ie. all documentation is properly
annotated with `// rustdoc-stripper-ignore-next`.
The generator does not read Gir.toml from dependencies, missing out on
trait renames like `ObjectExt` turning into GstObjectExt` (to prevent
clashes with `glib`'s `ObjectExt`). Renaming through `trait_name` is
now taken into account in `gir` thanks to [1], but the renames still
need to be availble to all crates referencing this type. Fortunately
only `Gst.Object` is affected - other renamed traits are not extended in
any of the other crates.
[1]: https://github.com/gtk-rs/gir/pull/1108
When importing the prelude of a crate like `gst` the `glib` prelude is
provided too. Shedding these imports saves quite a few lines and
adheres to keeping it simple; we're not reexporting base/parent preludes
for no reason :)
