Currently, gst-uninstalled is using sitecustomize.py for adding gi
override tweaks. However, if the standard Python libraries come before
this file in sys.path, then sitecustomize.py will never be run because
the "import sitecustomize" done in site.py will use the standard Python
libraries instead. This can be seen by running "import sitecustomize;
print(sitecustomize.__file__)" inside the uninstalled environment, as
well as by checking gi.override.__path__ and seeing that the tweaks are
missing (and the overrides are misbehaving).
Switch to using usercustomize.py, which has no match in the standard
libraries and thus will be correctly imported.
https://bugzilla.gnome.org/show_bug.cgi?id=797011
We should not default to -Werror because that's not what we default to
anywhere in gstreamer, and it's bad for releases anyway. The CI will
be fixed to pass --werror manually.
Don't assume that meson is always a python script, on Windows it can
be (and soon will almost always be) an executable.
See: Meson MSI installer and https://github.com/mesonbuild/meson/pull/4004
Meson was literally trying to check out tag/revision
'a1b3f07c5271f312997fcc3451237031444c4475 # 1.8.0 + fix for gcc 8.'
which doesn't exist of course.
Can be re-enabled again if we check for all direct and
indirect hard deps before including it.
subprojects\gtk-sharp\Source\meson.build:40:0: ERROR: Program(s) ['gacutil'] not found or not executable
This would not trigger on the build bot because there is
special casing in the code for a meson checkout underneath
gst-build. Fix needed as mesonintrospect.py was changed into
'meson.py introspect' in recent meson versions. When using
meson from git to configure the build the uninstalled script
would pick up a system meson instead which then would then
error out parsing the coredata from the newer meson.
The proxy-libintl meson build files have been upstreamed, so we do not
need to use Centricular's git repository anymore.
Glib has moved to GNOME's Gitlab instance, and we use a specific branch
on it to get override_find_program for glib tools.
This is still incredibly ugly, but at least now mesonconfig
gets found, unlike before where the path where it was looked
for was the path of the sitecustomize symlink, not of its target
(https://bugs.python.org/issue6386)
virtualenv ships its own version of site.py, which does not
expose a getusersitepackages function. An alternative method
is thus used when we detect that we are running in a virtualenv.