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
