On windows, if you are not using built-in commands you need
to pass the full path of your executable into the subprocess.call/
Popen syscall. ex `c:/foo/bar/baz.exe`. This get's long and is
not ergonomic when you want to run trivial task like:
`gst-env.py ninja` or `gst-inspect0.0` or `gst-validate-launcher`
Instead, on windows, always launch a shell to be able to resolve
the executable from the PATH.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2397>
As described in Merge request 222, the previous solution is not the
best possible solution and was also missing documentation.
Adjust the suggestion to the current GStreamer mono-repository.
And apply this change after reverting the previous commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
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>
This is not actually needed because everything we build is using
@rpath already, and setting it causes dynamic linker path priority
issues with macOS internals causing *all* programs to fail to run
inside gst-env:
```
$ vim
dyld: Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
Expected in: /Users/nirbheek/projects/repos/gst-build/_build_macos/subprojects/libjpeg-turbo-2.1.0/libJPEG.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
Abort trap: 6
```
In this case it is caused by libjpeg.dylib, but it can happen with
other dylibs that conflict with dylibs used by macOS internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/257>
At the point of get_windows_shell() execution, the current directory
equals DEFAULT_BUILDDIR=./build. But cmd_or_ps.ps1 is in SCRIPTDIR=./
(repo root). Point subprocess.check_output() to the correct directory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/238>
The pcfile argument passed to get_target_install_filename() is
guaranteed to be a Path() object so use the .open() method to open the
file instead of the standard open() function.
This makes it possible to run gst-env.py on older systems with pyhton3.5
where the standard open() function cannot handle Path arguments.
The change fixes errors like the following:
-----------------------------------------------------------------------
$ ninja -C build/ devenv
ninja: Entering directory `build/'
[0/1] Running external command devenv
Traceback (most recent call last):
File "/home/ao2/gst-build/gst-env.py", line 493, in <module>
env = get_subprocess_env(options, gst_version)
File "/home/ao2/gst-build/gst-env.py", line 342, in get_subprocess_env
elif is_gio_module(target, filename, options.builddir):
File "/home/ao2/gst-build/gst-env.py", line 121, in is_gio_module
giomoduledir = PurePath(get_pkgconfig_variable(builddir, 'gio-2.0', 'giomoduledir'))
File "/home/ao2/gst-build/gst-env.py", line 110, in get_pkgconfig_variable
return get_pkgconfig_variable_from_pcfile(pcfile, varname)
File "/home/ao2/gst-build/gst-env.py", line 89, in get_pkgconfig_variable_from_pcfile
with open(pcfile, 'r', encoding='utf-8') as f:
TypeError: invalid file: PosixPath('/home/ao2/gst-build/build/meson-private/gio-2.0.pc')
FAILED: meson-devenv
-----------------------------------------------------------------------
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/192>
Python `set`s have a random ordering. To avoid creating a random
environment, create sorted lists before iterating over them.
Our Rust crates instruct cargo to rebuild if `PKG_CONFIG_PATH` changes,
so this has been causing unnecessary rebuilds.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/177>
`bdir[1:]` is supposed to convert `/path/to/bdir` to `path/to/bdir`
which is only correct on UNIX. On Windows it will convert
`C:\path\to\bdir` to `:\path\to\bdir` which is totally wrong.
Use pathlib instead, which makes it trivial to do the conversion using
`joinpath(*bdir.parts)`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/160>
This is needed to use gst-uninstalled mode over NFS when gst-build is a
worktree. When this is the case, the .git is a file that links to the original
git tree, but this tree is unlikely to be visible over NFS. Instead of forcing
NFS contorsion, simply ignore the error.
allow for workflows that don't want the gst scripts to start shells,
this can be awkward for higher-level scripts setting up shells
themselves.
this is especially useful in combination with eval, and mimics the sort
of thing you can do with ssh-agent -s.
So gst-build/prefix/etc/xdg/tizonia/tizonia.conf can be found.
Which one contains path to tizonia plugins. Useful when
compiling tizonia-openmax-il and installing it in gst-build
's prefix location:
autoreconf -ifs
./configure --disable-player
--without-libspotify
--prefix=path_to_gst-build/prefix/
make && make install
Allows the following to work:
gst-launch-1.0 videotestsrc ! vp8enc ! omxvp8dec ! xvimagesink
This is the wrong operator to use, which only seems to work because
`os.name` and `'nt'` happen to be the same object. Python 3.8 also
produces a `SyntaxWarning` when encountering this pattern.
On Linux, the library file is stored in the platform triplet directory under the
lib directory (hence for example
lib/x86_64-linux-gnu/gstreamer-1.0/libgstfoo.so) so the regex needs to take this
into account.
With this change the LD_LIBRARY_PATH on Linux now contains only the directories
with gst libs, ignoring the plugins, as initially intended in
c6613d8da2.
Fixes#56
At least in Meson 0.49, the target['install_name'] is a string, not a list, so
the heuristics declared in the is_library_target_and_not_plugin() can't apply
because Python is actually happy to iterate over a string without any warning.
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.
