`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.
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.
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
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.
