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
`add` behaves the same as before. `rm` removes worktrees.
`git worktree remove` on the gst-build worktree will delete the
subproject worktrees inside it, but will not remove the references to
them in the main repository's subproject worktrees. The `rm` command
will.
It's pretty common to have the same branch for a subproject in
multiple worktrees. F.ex., when you want to test a feature branch
common to a few gstreamer subprojects but not the rest.
meson introspect is the wrong approach since it:
* Requires a pre-existing build directory for some branch
* Gives us potentially incorrect information since it tells us
subproject details for the current branch, not the branch we're
checking out.
* Does not allow us to share the git repos for non-gst repos since it
can't tell us the git branches for them.
Instead, parse the wrap files in the branch we're checking out since
they're just INI-style config files.
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.
Enable following warnings
- unused variable
- unhandled enum value in switch/case
Those warnings might cause build error on CI pipeline, but not enabled
by default. For development environment, let's enable them to save
CI (and developer's time) resource.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-build/issues/31
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.
The old binary/url is no longer available, and the layout of the
sourceforge archvie seems to have changed to include a new
old_versions/ directory where the previous binary is
relocated.
https://sourceforge.net/projects/winflexbison/files/old_versions/
While we could use that, it seem better to invest the effort to
adapt the scipt afterwards to use the github archives instead
https://github.com/lexxmark/winflexbison/releases
So for now bump the version to get the subproject building
till we switch to github releases.
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.
People should not run `meson` on gst-build inside the uninstalled env.
It will cause problems because meson will detect the already-built
libraries and pkg-config files.
This is not obvious to people, and they often make this mistake.
