Yielding option means that if pango is built as a subproject, it will
take the value of that option from the parent project (e.g. gst-build).
For that to work it must be of the same type, which is "feature" instead
of "boolean" in all GStreamer modules.
I added libcloudproviders to the base image, but
now I see that we already enabled libcloudproviders
in the build anyway, so I'm a bit confused.
Fixes: #2480
Use feature options for things that are optional features,
update the docs.
Visible changes here is that the 'print-backends' option
got renamed to 'print' to go better with 'media', and the
'tracker3' option got renamed to 'tracker'.
For options that have been changed into features, the
syntax now is -Dfeature=enabled or -Dfeature=disabled
or -Dfeature=auto.
We don't support any profilers other than sysprof,
so name the option accordingly. While we are at it,
change it to a meson feature option, so
-Dprofiler=true becomes -Dsysprof=enabled
Run our testsuite under asan. We do this in a
separate build, since we need to turn off
introspection to make the build succeed.
As Michael Catanzaro pointed out, this requires a
privileged runner in order to use kernel apis.
Currently we have to hunt all the `image` keys when updating the image
in use for a job. We should centralise them all at the top of the file,
so they are easy to update in one simple change.
It doesn't understand the powershell syntax which leads to the cache
key being empty which leads to cache restore being skipped
which leads to slow builds not using ccache.
See https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2747
They use powershell instead of cmd.exe, use the tag win32-ps instead of win32,
and run Windows 2016 instead of 2012r2.
The old runners will be switched off in the comming weeks.
We need to investigate release-specific failures, and possibly fix our
test suite to deal with debug-specific poking through the internal
state.
For the time being, allow the release job to fail, but this is strictly
a temporary measure.
We are going to need to hide the report generation into the test runner
script, as we want the job to produce the reports even in case of
failure, instead of bailing out immediately.
Now that we figured out why the build was failing on Fedora when the
profiling code was enabled, we can go back to building both shared and
static libraries by default.
We should have a single job for building both static and shared
versions of GTK. On the other hand, having a separate job for the
release build would be a plus.
Additionally, we shouldn't use an opaque script to build GTK; the only
step in the process that requires hand-holding is running the tests
suites under Xvfb, and having the build options visible from the YAML
file gives us a better idea of what kind of build we're running.
