These options allow to select a set of features from a given
plugin with the following syntax:
-Dgst-full-plugins=plugin1;plugin10
-Dgst-full-elements=plugin2:element1,element2
-Dgst-full-typefind-functions=plugins3:func
-Dgst-full-device-providers=plugin4,dp1
-Dgst-full-dynamic-types=plugin5:dt1
By default all the enabled plugin are registered and
gst-full-plugins will allow to include only a set of plugin
If a feature(element, typefind etc.) is selected from a plugin,
the plugin is removed from the plugins list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199>
Can be used to control the exact symbols exported, or not, in
libgstreamer-full.
This is useful when building a tailored libgstreamer-full aimed
to be run with some specific binaries. By using such version script
one can reduce the size of the generated lib by letting the linker
garbage collect all the unused APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/195>
When building with -Ddefault_library=static, also build a single library
containing all built plugins. Any external dependencies are still
dynamically linked.
A monolithic library is easier to distribute, and in some envs like
Android is required.
Having vaapi decoders/encoders accidentally available by default often
causes strange test failures or weird behaviour since the plugins are
sometimes buggy or have different behaviour.
The only requirement for the rust plugins is that a rust toolchain be
present on the system. This is problematic:
1. This means gst-build on Windows is broken by default if you have
a Rust toolchain, since glib can't be used uninstalled
2. No output is printed on Windows at all while the rust plugins are
being built. `custom_target()`'s `console:` keyword argument seems
to be broken on some Windows shells.
3. Even on Linux/macOS having this enabled by default is problematic
since it more than doubles the total build time.
4. The biggest issue with having it enabled by default is that it does
not dependency tracking, so we always run `cargo`, which might
update crates. This increases friction when you're working on
unrelated code.
When relying on a system-wide libnice, we end up not building
the nice elements, which means we can't use them, and by extension
webrtcbin, in the uninstalled environment.
This also introduces a way to avoid checking the version of
a given subproject, and makes use of it for libnice and pygobject,
which only passed the version check by chance, as its current
major version is 3.
Can be re-enabled again if we check for all direct and
indirect hard deps before including it.
subprojects\gtk-sharp\Source\meson.build:40:0: ERROR: Program(s) ['gacutil'] not found or not executable
