The usual use of this will be through the `ElementImpl::metadata`
method, which requires a `&'static` reference to `ElementMetadata` to be
returned, so we better make it easy to construct these (without forcing
people to resort to `Lazy`'n'stuff)
Attributes don't do anything when applied to macro invocations:
warning: unused attribute `doc`
--> gstreamer/src/lib.rs:146:29
|
146 | #[cfg_attr(feature = "dox", doc(cfg(feature = "v1_14")))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_attributes)]` on by default
note: the built-in attribute `doc` will be ignored, since it's applied to the macro invocation `cfg_if::cfg_if`
--> gstreamer/src/lib.rs:147:1
|
147 | cfg_if::cfg_if! {
| ^^^^^^^^^^^^^^
And, on line 294-295:
warning: unused attribute `doc`
--> gstreamer/src/lib.rs:294:33
|
294 | #[cfg_attr(feature = "dox", doc(cfg(feature = "v1_14")))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: the built-in attribute `doc` will be ignored, since it's applied to the macro invocation `cfg_if::cfg_if`
--> gstreamer/src/lib.rs:295:5
|
295 | cfg_if::cfg_if! {
| ^^^^^^^^^^^^^^
Fortunately these two `cfg_if`'s for the Unix and Windows bus already
apply unnecessary trickery that duplicates the `mod`s and `use`s in
order to get documenation for both no matter the target platform; we can
capitalize on that by removing the `cfg_if` altogether and instead
applying the `cfg` and `doc(cfg())` attributes directly.
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.
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`.
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 :)
This was temporarily allowed by Value trait refactoring, but the root
cause of the unused imports has been found (`glib::ToValue` for property
getters) and fixed in https://github.com/gtk-rs/gir/pull/1117.
In gir it was brought up [1] that some traits (in particular
`*ExtManual`) are exported from the crate root in addition to the
prelude, cluttering the environment unnecessarily. This commit removes
all these reexports, leaving those in prelude (that were already there)
only.
After this commit everything matching `Ext(Manual)?\b` in `lib.rs` sits
within `pub mod prelude {};`.
[1]: https://github.com/gtk-rs/gir/pull/1111
The `lgpl-docs` and documentation embedding step is now solely invoked
from `./gir/generator.py` in the CI, and does not need the embed/purge
build features anymore.
The `lgpl-docs` crate and all precompiled (easy to get outdated!)
docmentation files are removed in favour of being generated at runtime
by the improved generator, both during local development as well as in
the CI.
The previous commit reinstantiated `girs_dir`, and this commit applies
the rename to `girs_directories` and adds the new/missing
`gst-gir-files` directory where GStreamer-specific `.gir` files live.
This reverts commit 7f9fcb09e2.
`generator.py` is in the process of being moved to a generic place in
the `gir` repository for reuse across crates. This means `-d` cannot be
passed for our GStreamer-specific `gst-gir-files` directory anymore, and
should be configured from `Gir.toml` instead.
We can't return a plain reference to something stored inside the future
as that would go out of scope after `await`. Instead return a struct
that wraps the `gst::Promise`, derefs to a structure and keeps the
promise alive as long as needed.
See https://github.com/gtk-rs/gtk-rs/pull/449. This struct remains
vital in GStreamer code to tie a type to an (untyped) SendValue, so that
the underlying value can be retrieved without having to guess its type.
That type is anyway stored in a private member T::TagType.
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Gir now prints all directories and their hashes in the version file and
comments; useful now that gstreamer-rs is being generated from both
gir-files/ and gst-gir-files/ submodules.
We were already using `gir -d` and especially now that our files are
separated across two directories that are relative to the directory
containing Gir.toml this only becomes cumbersome. Besides `gir` lacks
functionality to normalize the path, leading to ie.
gstreamer-gl/egl/sys/../../../gir-files in the version comment as a
result.
This scales better as there will only be only such data instead of two
or more when having deeper class hierarchies with multiple Rust
elements, and also makes it unnecessary to use a special instance struct
so the default works well.
While this allows to remove the pad probe multiple times, which would
cause a g_warning(), this is not actually making the situation worse
than before while making some code patterns easier to implement:
- Probes could already be removed twice by return
gst::PadProbeReturn::Remove and then calling pad.remove_probe()
- Probes could be removed from a different pad than where they were
added
As such let's go with the simple solution here for now and allow giving
owned access to the probe id from the probe callback.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/286
Make it an actual bitflags type instead of just an u64 alias and add all
the constants. As it's not defined as bitflags in C this needs to be
done manually.
This should be analogous to C struct initalizers where all unspecified
fields are initialized to zero. Without mut this reads a bit nicer as
well.
Note that two out of three structs have all members specified, hence
need no zero-initialization of the remainder at all.
