The modules format and clock_time share common macros which are
scattered between each modules. This cross reference makes it
difficult to maintain the macros.
This commit also make it possible to use macro
impl_common_ops_for_newtype_uint for Percent.
These operations were implemented using the integer implementations.
These types' MAX values are different from the integers so they must
use specific implementations.
Also add the overflowing variants.
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.
