After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 619815 - GST_PLUGIN_LOADING_WHITELIST env var for unit tests
GST_PLUGIN_LOADING_WHITELIST env var for unit tests
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.10.30
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 619717
 
 
Reported: 2010-05-27 12:05 UTC by Tim-Philipp Müller
Modified: 2010-06-24 11:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pluginloading: add support for whitelisting based on package name and path (7.02 KB, patch)
2010-05-27 12:05 UTC, Tim-Philipp Müller
none Details | Review
pluginloading: add support for whitelisting based on package name and path (2nd patch) (7.03 KB, patch)
2010-05-27 13:23 UTC, Tim-Philipp Müller
none Details | Review

Description Tim-Philipp Müller 2010-05-27 12:05:36 UTC
Created attachment 162091 [details] [review]
pluginloading: add support for whitelisting based on package 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 package-name@path-prefix pairs separated by the platform
    search path separator (G_SEARCHPATH_SEPARATOR_S). Package name and
    path prefix are separated by the '@' character. The path prefix is
    entirely optional, and so is the '@' separator if no path is given.
    
    So for our gst-plugins-good unit test case above, this would be:
    gstreamer:gst-plugins-base:gst-plugins-good@/src/gst-plugins-good/
Comment 1 Tim-Philipp Müller 2010-05-27 12:07:44 UTC
Note that the build servers also run into this problem (some -bad plugin screws up in plugin init -> unit tests in good/base/wherever fail, which is just not very useful).
Comment 2 Benjamin Otte (Company) 2010-05-27 12:56:51 UTC
Doesn't this fail spectacularly if people pass --with-package-name='Fedora GStreamer packages' to configure?

I'd rather whitelist based on a variable that cannot be modified by configure options. Unfortunately, I cannot come up with anything but the element or plugin name. And that might make the list a bit long for some tests I suppose?
Comment 3 Tim-Philipp Müller 2010-05-27 13:09:38 UTC
> Doesn't this fail spectacularly if people pass --with-package-name='Fedora
> GStreamer packages' to configure?
> 
> I'd rather whitelist based on a variable that cannot be modified by configure
> options. Unfortunately, I cannot come up with anything but the element or
> plugin name. And that might make the list a bit long for some tests I suppose?

Right, this is just me being confused. I should be checking GstPluginDesc::source (which contains the autotools-set PACKAGE), not GstPluginDesc::package (which contains the free-form package name).
Comment 4 Tim-Philipp Müller 2010-05-27 13:23:38 UTC
Created attachment 162094 [details] [review]
pluginloading: add support for whitelisting based on package name and path (2nd patch)

Second attempt: same as above, but check the autotools-set source package identifier rather than the configurable free-form package name.
Comment 5 Tim-Philipp Müller 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@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@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@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@pathprefix or
       plugin1,plugin2@* or just
       plugin1,plugin2 or
       source-package@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.