As GNU indent version can be different on the user system, we see some
differences during migration thas causes conflicts. Making cherry-pick
difficults to recover without breaking the style temporily. Note that
cherry-pick continuation does not allow passing the -n option to skip
the hooks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1017>
Main differences with previous setup are:
- No manifest creation
- gst-indent is executed only when the bot is assigned (instead of the manifest task)
- Cerbero jobs are triggered in the cerbero repo
- Remove cerbero and android related files as they now are in cerbero
itself.
- Update `container.ps1` to the new file layout
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/891>
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>
This is a workaround for a Meson bug that incorrectly trigger
reconfigure when files change in build directory. This commit can be
reverted once GStreamer depends on Meson >=0.54.0.
See https://github.com/mesonbuild/meson/pull/6770Fixes: #85
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.
This is the wrong operator to use, which only seems to work because
`os.name` and `'nt'` happen to be the same object. Python 3.8 also
produces a `SyntaxWarning` when encountering this pattern.
This is useful to check that a build didn't result in changes in the
code/generated files
This will be used to check that the plugins documentation cache file is
properly commited, and that necessary workaround for particular case
are adopted.
To build the documentation, we are maintaining a 'standardise' `plugins`
variable accross all modules to list all plugins and generate
documentation for them.
This is also used to get the right plugin path when inspecting plugins
for the documentation.
