The documentation within meson highlights, that `ninja` can be used
without problems for any case except `ninja reconfigure`. The warning
however describes to the user, that `ninja` shouldn't be used at all.
Fix the warning.
Fixes: 01eb252f67 Don't allow people to run meson inside the uninstalled env
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
Remove the symbolic link `gst-uninstalled` which points to `gst-env`.
The `uninstalled` is the old name and the project should stick to a
single name for the procedure.
Remove the term from all the files, exceptions are variables from
dependencies like `uninstalled_variables` from pkgconfig and
`meson-uninstalled`.
Adjust mentions of the script in the documentation and README.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
Meson now explicitly blacklists pkg-config.bat from Strawberry Perl and
thus building GStreamer on Windows has been fixed.
This allows for instance to build GStreamer on GitHub Action Windows
runners that have Strawberry Perl by default.
It is also useful when needing to build OpenSSL on the same Windows
machine because it requires Perl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1263>
For monorepo build and ugly/bad, for advanced feature
option API like get_option('xyz').required(..) which
we use in combination with the 'gpl' option.
For rest of modules for consistency (people will likely
use newer features based on the top-level requirement).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1084>
Due to a bug, meson ignores ${lang}_std settings in default_options
for subprojects: https://github.com/mesonbuild/meson/issues/1889
This causes build failures when a subproject requires c++11 or c++14,
etc. Compilers that support those cpp_stds are very common, and all
the toolchains that we support include c++ compilers, so we can
add cpp_std=c++14 to the top-level.
This fixes the webrtc-audio-processing build on Linux, and harfbuzz on
macOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1133>
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.
