docs/pwg/building-testapp.xml: Mention that GST_PLUGIN_PATH or --gst-plugin-path might be needed if people try to bui...

Original commit message from CVS:
Patch by: Steve Fink  <sphink gmail com>
* docs/pwg/building-testapp.xml:
Mention that GST_PLUGIN_PATH or --gst-plugin-path might be needed
if people try to build or install the example from the plugin
template against a GStreamer from package using the configure
defaults.
This commit is contained in:
Steve Fink 2007-07-26 08:46:46 +00:00 committed by Tim-Philipp Müller
parent 3dc3b453db
commit 896e1a3d5d
2 changed files with 20 additions and 1 deletions

View file

@ -1,3 +1,13 @@
2007-07-26 Tim-Philipp Müller <tim at centricular dot net>
Patch by: Steve Fink <sphink gmail com>
* docs/pwg/building-testapp.xml:
Mention that GST_PLUGIN_PATH or --gst-plugin-path might be needed
if people try to build or install the example from the plugin
template against a GStreamer from package using the configure
defaults.
2007-07-25 Tim-Philipp Müller <tim at centricular dot net>
Patch by: Steve Fink <sphink gmail com>

View file

@ -5,7 +5,16 @@
<para>
Often, you will want to test your newly written plugin in an as small
setting as possible. Usually, <filename>gst-launch</filename> is a
good first step at testing a plugin. However, you will often need more
good first step at testing a plugin. If you have not installed your
plugin in a directory that GStreamer searches, then you will need to
set the plugin path. Either set GST_PLUGIN_PATH to the directory
containing your plugin, or use the command-line option --gst-plugin-path.
If you based your plugin off of the gst-plugin template, then this
will look something like
<command>
gst-launch --gst-plugin-path=$HOME/gst-template/gst-plugin/src/.libs TESTPIPELINE
</command>
However, you will often need more
testing features than gst-launch can provide, such as seeking, events,
interactivity and more. Writing your own small testing program is the
easiest way to accomplish this. This section explains - in a few words