gstreamer/testsuite/plugin
Andy Wingo fbbdca6996 GST_PLUGIN_PATH gets split into the user registry some debugging output in registry rebuilding don't go into =build, ...
Original commit message from CVS:
* GST_PLUGIN_PATH gets split into the user registry
* some debugging output in registry rebuilding
* don't go into =build, =inst, etc
* i really don't know what the current idiom is for the plugin test suites, disabling for now

still pending issues: what to do when other plugin paths are passed on the command
line for existing registries. if the existing registries were built against those
paths, the time checks work, but if not they will need to be rebuilt. i have a feeling
they should be rebuilt in any case, but it's a tricky issue.
2002-05-10 03:27:42 +00:00
..
.gitignore Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
dynamic.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
linked.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
loading.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
Makefile.am GST_PLUGIN_PATH gets split into the user registry some debugging output in registry rebuilding don't go into =build, ... 2002-05-10 03:27:42 +00:00
README Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
registry.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
static.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
static2.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
testplugin.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
testplugin2.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
testplugin2_s.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00
testplugin_s.c Lots of modifications to the plugin system. 2001-08-21 20:16:48 +00:00

The following plugin modes are supported:

1) registry based 
-----------------

All known plugins are listed in the registry file.

  gst_plugin_find ("pluginname");

Works right after gst_init (), along with the elements in it.
dynamic loading of the plugin is performed when a feature inside 
it is requested.

example: registry.c. (You might want to run gstreamer-register with
the --gst-plugin-path=. to added the test dir to the plugin path so
that the testplugins can be found)


2) non registry based, dynmic loading
-------------------------------------

Plugins are know after a gst_plugin_load ("pluginname"). This 
function will scan de plugin paths, so you might want to perform
a gst_plugin_add_path ("path").

After the gst_plugin_load(), the features are available without any
further actions.

example: dynamic.c


3) non registry based, shared linking
-------------------------------------

You can add the plugin .so (or equivalent) file to the LDFLAGS at 
compile time. The plugin will be known after the gst_init() without
any further actions.

example: linked.c


4) non registry based, static linking
-------------------------------------

Plugin compiled with the GST_PLUGIN_STATIC defined can be statically
linked to the executable. The plugin is available after gst_init () 
without any further actions.

example: static.c (plugins are statically linked from another file)
         static2.c (plugins are included in the main file)


Any combination of the above is possible too, for example, you can use
a registry, have some plugins load dynamically and have another few
linked in as a shared lib. 

You cannot statically link multiple plugins that are compiled without the
GST_PLUGIN_STATIC symbol defined (this will cause multiple defined at link
time for obvious reasons)