Since 547570cd79 we do not always build
PyGObject and our development environment is broken when trying to use
GStreamer python when built against system PyGObject with the following
error importing Gst in there:
```
12345678** (gst-plugin-scanner:710617): CRITICAL **: 11:45:02.343: can't find gi.repository.Gst
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/gi/repository/__init__.py", line 23, in <module>
from ..importer import DynamicImporter
File "/usr/lib64/python3.9/site-packages/gi/importer.py", line 33, in <module>
from .overrides import load_overrides
ImportError: cannot import name 'load_overrides' from 'gi.overrides' (/var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-editing-services/bindings/python/gi/overrides/__init__.py)
Factory Details:
```
The approach to fixing it is to implement override `gi` in
`gst-python/gi/` which we add to `PYTHONPATH`) and in there reset the
`gi` module to the right place and we get overrides from paths from
`_GI_OVERRIDES_PATH` we set in `gst-env.py` which points to all the
overrides that will be installed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1155>
If pygobject is available on the system, its version is new enough,
don't build the older pygobject and rely on that system one.
This fixes totem not being able to use libpeas' Python support.
** (totem:544972): WARNING **: 12:04:05.407: Error initializing Python Plugin Loader: PyGObject initialization failed
ImportError: could not import gobject (version mismatch, 3.40.1 is required, found 3.38.1)
Closes: #806
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1135>
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>
These get added to *all* subprojects, including ones we do not
maintain such as ffmpeg which then emits thousands of warnings that
completely overwhelm the compile output.
We will add these in each gstreamer subproject separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/223>
In a fully static link where an app link with gstreamer-full
the gst_init_static_plugins can be discarded because
no one references it.
Indeed the symbol is looked up by gst_init to call if it exists
and so it is not clearly referenced.
In order to avoid this issue, we use the linker flag
--undefined=gst_init_static_plugins to keep
the symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/207>
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>
That header is not needed any more because gst_init() now calls
gst_init_static_plugins() automatically when available.
This is an API break compared to 1.18, but release notes made it clear
it was an experimental feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/191>
If a static build is requested and x264 plugin has been enabled
the full link fails with:
/usr/bin/ld: subprojects/x264/libx264.a(cabac-a.o): relocation
R_X86_64_PC32 against symbol `x264_cabac_range_lps' can not be used when
making a shared object; recompile with -fPIC
Fixes#108
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/169>
Latest libnice requires 0.52, so it probably makes sense to
update the meson requirement in gst-build for that, so we
have good out-of-the-box developer experience for people,
with webrtc working out of the box.
Might also make it easier to backport things later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/164>
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.
Enable following warnings
- unused variable
- unhandled enum value in switch/case
Those warnings might cause build error on CI pipeline, but not enabled
by default. For development environment, let's enable them to save
CI (and developer's time) resource.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-build/issues/31
In the case of wine, the env can not be uninstalled, also developers
do not necessiraly care about the fact that it is "uninstalled", the
important thing is that it is a development environment, meaning
that they can work on GStreamer or with GStreamer in the environment.
I still keep the `uninstalled` target to avoid changing people's
habits for now.
People should not run `meson` on gst-build inside the uninstalled env.
It will cause problems because meson will detect the already-built
libraries and pkg-config files.
This is not obvious to people, and they often make this mistake.
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
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.
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.
Use an array instead of a dict to make sure we iterate over
the list of subprojects in the right order, which is first
GStreamer core, then gst-plugins-base, then other things.
Without this subprojects might get configured in random order,
in which case gstreamer or gst-plugins-base libs might get picked
up via pkg-config if they are also available installed, instead of
being picked up from the subproject. This breaks all kinds of
assumptions in gst-build and will likely have strange effects
and/or lead to build failures such as
subprojects/gst-plugins-good/tests/check/meson.build:144:2:
ERROR: 'gstreamer-plugins-base-1.0' is not a pkgconfig dependency
Since gst-devtools checks for gst-rtsp-server and will
happily pick up an external dep which isn't what we want
if we configure it as subproject afterwards.
This assumes meson dicts are always stable, which may
not necessarily be the case, but it seems to work in
practice for now.
See #16
This to simplify the checks made when for example a flex binary
is available system wide: the build process was failing when
that system wide binary didn't have the required version. Instead
of adding more checks and making things more complex, let's just
always use our binary subproject.
This is the same fix we used in gstreaemr-vaapi to blacklist
the notoroious libva version 0.99.0
Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped
its API version to 1.0.0. Thus we have to blacklist only the MSDK's
libva (0.99.0)
https://bugzilla.gnome.org/show_bug.cgi?id=789744
