Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
When a plugin declares a dependency using this flag, all the
relative paths are considered to be relative to the path of
the main executable.
We try to determine the path of the executable portably,
with implementations provided for Linux, Windows and Mac.
If retrieval of the path fails, we will not detect changes.
In order for the main executable path to be the same when
scanning a plugin in a child process, a new variable is
exposed in gst_private.h, _gst_executable_path
https://bugzilla.gnome.org/show_bug.cgi?id=788152
This patch changes the entry point of each plugin in order to unify the
interface for static and dynamic plugin. What we do is replace the
current static plugin interface and extend the dymamic one. The plugin
entry was a C structure, name "gst_plugin_desc". With this patch, the
interface is now:
GstPpluginDesc *gst_plugin_<name>_get_desc(void);
The reason we change the C structure into function, is that it is
potentially more common to have function pointers, avoiding possible
binding language limitation. Additionally to that. This change prevents
the symbols from clashing between plugins, allowing to build once the
plugin (assuming you have -fPIC).
On the plugin loader side, we symply derive the shared object basename
to extract the plugin name. If this symbol is not found, we fallback to
gst_plugin_desc for backward compatibility.
This has one side effect, which is that the shared objects now need to
be named after their plugin name. This is generally the case with few
exceptions. The benifit of this limitation is that you can control the
gst_plugin_<name>_desc clash at file level.
https://bugzilla.gnome.org/show_bug.cgi?id=779344
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.
