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.
If automatic bash prompt override is enabled via the 'GST_BUILD_DISABLE_PS1_OVERRIDE',
We should set the bash prompt to have a visual indicator of the "gst-uninstalled" environment
even if bash script file does not exist.
On Fedora 64-bit, libdir is 'lib64'. Just add it unconditionally
everywhere because we have no reliable way of detecting which distros
or OSes will use that.
This option was added so we could remove the sysroot path from the env
when cross-build is used over NFS. Though, the implementation wasn't complete
and went unnoticed.
This moves the sysroot path removal into the helper that prepends env so
that no more env get forgotten. This notably fixes the PATH environment.
When using hotdoc, one can build the documentation for a single
subproject (eg. the GL plugins). In that case, hotdoc will look
up links in devhelp indexes available in standard locations.
To make sure this case works, we thus need to add the path to
our devhelp index to XDG_DATA_DIRS. This also means when running
devhelp from inside the environment, the devhelp books produced
by hotdoc will now show up.
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.
As the data from meson is no longer relative path, it is not longer
possible to move gst-build around and run gst-uninstalled.py. This broke
cross-compilation usage, where you build on a host and run over NFS on
target. This adds an option to tell the script to strip off the host path
to the sysroot.
This is needed for using the qmlgl out of the box inside
gst-uninstalled. Of course this won't work if the user is using
a native file to specify the path to `qmake`.
... depending on detected shell program. For instance,
if the nearest ancestor process is PowerShell, run uninstalled
environment via PowerShell. Otherwise, $COMSPEC (most likely cmd.exe)
will be used.
When using a custom prompt the automatic override may not look good, so
provide a mechanism to disable it.
Document that the user will have to use GST_ENV manually when setting
the prompt to have a visual indicator of the gst-uninstalled
environment.
Starting with Meson 0.50, meson instrospect --targets uses a list
for the filename and install_filenames of each target. Handle both
lists and strings.
Currently gst-uninstalled.py changes the current directory to the root
of the gst-build before executing execute the command passed as
arguments. This is unnecessary, it creates confusion and makes scripting
more cumbersome. This patch fixes that.
Validate plugins are automatically scanned from GST_VALIDATE_PLUGIN_PATH
instead. Adding them to GST_PLUGIN_PATH causes race conditions as the
plugins may be loaded before validate itself.
We now use a different approach to setting up our
uninstalled python environment:
We add the gst-python folder to PYTHONPATH, and it no
longer contains __init__.py files. This means that
import gi.overrides correctly loads pygobject's __init__
module, but import gi.overrides.Gst also works, as __init__
files are no longer required by python.
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
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
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.
Fix a couple small breakages with windows usage, (1) Add
sys.executable to a subprocess invocation and (2) escape a path
fragment that gets used in a regex.
https://bugzilla.gnome.org/show_bug.cgi?id=782026
