API: GST_PLUGIN_STATIC_DECLARE()
API: GST_PLUGIN_STATIC_REGISTER()
Based on a patch by Håvard Graff <havard.graff@tandberg.com>.
This now allows GST_PLUGIN_DEFINE() to create a static plugin if
GST_PLUGIN_BUILD_STATIC is defined. The resulting plugin can be
statically linked or dynamically linked during compilation but
can't be dynamically loaded during runtime.
Also adds GST_PLUGIN_STATIC_DECLARE() and GST_PLUGIN_STATIC_REGISTER(),
which allows to register a static linked plugin easily.
It is still required to manually register every single statically linked
plugin from inside the application as this can't be automated in a portable
way.
A new configure parameter --enable-static-plugins was added that allows
to build all plugins we build here as static plugins.
Fixes bug #667305.
Make GST_PLUGIN_DEFINE use G_STRINGIFY() to convert the name argument
into a meaningful string. The advantage of this is that `name' can be
expanded from other macros defined in the plug-in element.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=697872
It's only used internally, most other users will likely
want to use gst_registry_find_plugin() directly instead
(and if not, they can easily walk the list and doing the
strcmp themselves).
There's no reason anyone would want to derive from this, so
just make opaque until we manage to make all the private bits
private properly (which I'm not doing right now because it's
more invasive and I have registry modifications locally which
touch all that code as well).
This is an implementation detail really, and it's not
clear what anyone would do with this. It's unused as
far as I'm aware, so just remove it for now.
This is a string describing a date and/or date/time in a simple subset of
the ISO-8601 format, namely either "YYYY-MM-DD" or "YYYY-MM-DDTHH:MMZ" (with
'T' the date/time separator and the 'Z' indicating UTC).
The main purpose of this field is to keep track of plugin and element versions
on an absolute timeline, so it's possible to determine which one is newer when
comparing two date time numbers. This will allow us to express 'replaces'-type
relationships betweeen plugins and element factories in future, even across
different modules and plugin merges or splits (source module version numbers
aren't particularly useful here, since they can only meaningfully be compared
within the same module). It also allows applications and libraries to reliably
check that a plugin is recent enough without making assumptions about modules
or module versions.
We use a string here to keep things simple and clear, esp. on the build system
side of things.
https://bugzilla.gnome.org/show_bug.cgi?id=623040
See 8fe63000de for why having a TRUE/FALSE
return value is a bad idea.
I've scanned a few plugins and they generally get it wrong and aren't
unloadable when they return FALSE.
This changes some APIs in compatible ways:
- Some functions now take "const char *" arguments, not "char *"
- Some structs now have "conts char *" members, not "char *"
The changes may cause warnings when compiling with the right warning
flags. You've been warned.
Also adds -Wwrite-strings as a warning flag in configure.ac.
https://bugzilla.gnome.org/show_bug.cgi?id=611692
Original commit message from CVS:
* gst/gstplugin.h: (GST_PLUGIN_DEFINE_STATIC):
Remove deprecation guards around GST_PLUGIN_DEFINE_STATIC.
This makes gtk-doc complain, but results in slightly better
compiler errors. The old _gst_plugin_register_static() is
still guarded, so there'll be a compiler warning about that
instead. Fixes#510187 too.
Original commit message from CVS:
* gst/gst.c: (init_post):
* gst/gstplugin.c: (_gst_plugin_register_static),
(gst_plugin_register_static), (_gst_plugin_initialize):
* gst/gstplugin.h: (GstPluginFilter):
Change API of gst_plugin_register_static() to not take
a GstPluginDesc, but rather just take all the arguments
in a GstPluginDesc directly. This is more intuitive and
avoids certain mistakes when porting code from
GST_PLUGIN_DEFINE_STATIC to gst_plugin_register_static().
Fixes#510187.
* tests/check/gst/gstplugin.c:
Fix up for changed API.
Original commit message from CVS:
* docs/gst/gstreamer-sections.txt:
* gst/gst.c: (init_post):
* gst/gstplugin.c: (_gst_plugin_register_static),
(gst_plugin_register_static), (_gst_plugin_initialize),
(gst_plugin_register_func):
* gst/gstplugin.h: (GST_PLUGIN_DEFINE_STATIC):
API: add gst_plugin_register_static() and deprecate
GST_PLUGIN_DEFINE_STATIC, since it's not portable
(#498924).
Also, in _gst_plugin_register_static(), make sure to call
g_thread_init() before calling GLib functions such as
g_list_append() if we're not initialised yet, since that
may lead to random crashes with older GSlice/GLib versions.
* tests/check/gst/gstplugin.c:
Adapt unit test to above changes.
Original commit message from CVS:
* gst/gst_private.h:
* gst/gstbuffer.h:
* gst/gstevent.h:
* gst/gstformat.h:
* gst/gstmessage.h:
* gst/gstplugin.h:
* gst/gstquery.h:
* gst/gsttaglist.h:
* gst/gstvalue.h:
Move declaration of private _gst_foo_initialize() functions into
our private header file where they should have been all along.
Original commit message from CVS:
* gst/gstplugin.h:
Cast description string constants in GST_PLUGIN_DEFINE macros
to a (gchar*) to make C++ code using these macros compile
without warning with g++-4.2 (see #462737). Even if slightly
ugly, this seems preferable to putting the description strings
into the GLib quark table or making the structure member a
const gchar * and doing casts in core code that allocs and
frees these strings, or requiring a cast in the C++ code.
Original commit message from CVS:
* gst/gstplugin.c:
* gst/gstplugin.h:
* gst/gstregistrybinary.c:
* gst/gstregistryxml.c:
Put more strings into the GLib quark table. No need to keep
a hundred-something copies of identical version strings,
license strings, package name strings and package origin
strings around.
Original commit message from CVS:
* gst/gstplugin.c:
* gst/gstplugin.h:
Add the 3-clause BSD license and the MIT/X11 license to the license
list. Fixes#479784.
Original commit message from CVS:
* configure.ac:
* gst/Makefile.am:
* gst/gst.c:
* gst/gstplugin.h:
* gst/gstregistry.h:
* tests/benchmarks/complexity.c:
* tests/benchmarks/mass-elements.c:
* tests/check/Makefile.am:
* tools/Makefile.am:
* tools/gst-inspect.c:
* tools/gst-xmlinspect.c:
various fixes to make
--disable-nls --disable-registry --disable-loadsave --disable-parse --disable-gst-debug
work and get the core .so down to 360444 bytes after stripping
Original commit message from CVS:
2005-11-29 Andy Wingo <wingo@pobox.com>
* gst/gstevent.h (struct _GstEvent): Only one pointer of padding.
* gst/gststructure.h (struct _GstStructure): Only one pointer of
padding.
* gst/gstquery.h (struct _GstQuery): Only one pointer of padding.
* gst/gstpluginfeature.h: Remove a comment in PluginFeature.
* gst/gstplugin.h (struct _GstPluginClass): Add some padding.
* gst/gstobject.h: (struct _GstObject): Only one pointer of
padding; reduces object size by about 30%. We don't expect
anything else to go into gstobject.
* gst/gstminiobject.h (struct _GstMiniObject)
(struct _GstMiniObjectClass): Only one pointer of padding; the
payload is only a pointer and two ints anyway. For the class there
are only two methods as well.
* gst/gstelement.h (struct _GstElementClass): Removed
the state_changed signal callback, it is not used.
Original commit message from CVS:
* gst/gstplugin.c: (gst_plugin_finalize), (gst_plugin_load_file):
* gst/gstplugin.h:
* gst/gstregistry.c: (gst_registry_lookup_locked),
(gst_registry_scan_path_level):
* gst/gstregistryxml.c: (load_plugin):
Only ever load one plugin for a given plugin basename.
This ensures correct overriding of GST_PLUGIN_PATH over
GST_PLUGIN_SYSTEM_PATH and of home dir plugins over
system installed plugins.
Original commit message from CVS:
* docs/gst/.cvsignore:
* docs/gst/tmpl/.cvsignore:
* docs/gst/tmpl/gstpipeline.sgml:
* docs/gst/tmpl/gstplugin.sgml:
* gst/gstpipeline.c:
* gst/gstplugin.c:
* gst/gstplugin.h:
inlined the last two docs files
removed the tmpl directory from cvs (no more conflicts here!)
