[gstreamer-bugs] [Bug 619815] GST_PLUGIN_LOADING_WHITELIST env var for unit tests
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Thu Jun 24 04:57:20 PDT 2010
https://bugzilla.gnome.org/show_bug.cgi?id=619815
GStreamer | gstreamer (core) | git
Tim-Philipp Müller <t.i.m> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|HEAD |0.10.30
--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-06-24 11:57:16 UTC ---
Committed something along these lines, but allowing plugin-names too:
commit 3410d665d74609802818ef734439b4414a6943b9
Author: Tim-Philipp Müller <tim.muller at collabora.co.uk>
Date: Wed Jun 23 11:02:16 2010 +0100
binaryregistry: ignore the plugin cache if the filter environment has
changed
Make sure that we properly update the registry and the cache file whenever
the filter environment changes or there's no more filter set.
commit 9c6b87510e854c39b4a4e53e21325bb7ce5b6693
Author: Tim-Philipp Müller <tim.muller at collabora.co.uk>
Date: Thu May 27 12:36:10 2010 +0100
pluginloading: add support for whitelisting based on plugin or source
module name and path
This feature is primarily intended for use in plugin modules' unit tests.
Consider the following situation: gst-plugins-good is built against an
installed GStreamer core. An older version of gst-plugins-good is also
installed in that prefix, along with random other plugin modules. Now,
when doing 'make check' in the just-built gst-plugins-good tree, we
want to only load plugins from GStreamer core, gst-plugins-base, and
gst-plugins-good, but not random other modules (we don't want any unit
tests to fail just because some module in gst-plugins-bad has a broken
plugin_init, for example). Also, we want to only load gst-plugins-good
modules from the locally-built source tree, but not any of the older
gst-plugins-good modules installed. This is usually assured by loading
the ones in the source tree first (by adding that path first to the
right environment variables), but it gets tricky when plugins are
moved, removed, merged, or renamed, or the plugin filename changes.
Note that 'make check' should really work right without doing
'make install' or uninstalling the old gst-plugins-good package (or
any other gst-plugins-foo package) first.
Enter GST_PLUGIN_LOADING_WHITELIST. This environment variable may
contain source-package at path-prefix pairs separated by the platform
search path separator (G_SEARCHPATH_SEPARATOR_S). The source package
and path prefix are separated by the '@' character. The path prefix is
entirely optional, as is the '@' separator if no path is given.
It is also possible to filter based on plugin names instead of the name
of the source-package by specifying one or more plugin names separated
by commas before the optional path prefix.
In short, the following match patterns are possible:
plugin1,plugin2 at pathprefix or
plugin1,plugin2@* or just
plugin1,plugin2 or
source-package at pathprefix or
source-package@* or just
source-package
So for our gst-plugins-good unit test example above, we would set the
environment variable on *nix to something like this (will likely be a
relative path in practice):
gstreamer:gst-plugins-base:gst-plugins-good@/path/to/src/gst-plugins-good
Fixes #619815 and #619717.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list