[gstreamer-bugs] [Bug 510187] New: gst_plugin_register_static() API and GST_PLUGIN_DEFINE_STATIC deprecation review

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=510187

  GStreamer | gstreamer (core) | Ver: HEAD CVS
           Summary: gst_plugin_register_static() API and
                    GST_PLUGIN_DEFINE_STATIC deprecation review
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Recent postings to gstreamer-devel suggest that the newly-introduced
gst_plugin_register_static() API and the uncompromising deprecation of the
GST_PLUGIN_DEFINE_STATIC macro may not be ideal in their current state and
should at least be reviewed before release.

Two issues:

 (a) when -DGST_DISABLE_DEPRECATED is used, the compiler will throw a bunch
     of somewhat cryptic errors that aren't particularly helpful and don't
     indicate that the macro is not defined any longer because it has been
     deprecated. I can think of three possible resolutions:

      (a1) tough luck, that's what you get for compiling with that flag
           (ie. leave it as it is now)

      (a2) do something along the lines of:
             ...
           #else /* GST_DISABLE_DEPRECATED */
             #define FOO_STATIC(...) FOO_STATIC_has_been_deprecated
           #endif /* GST_DISABLE_DEPRECATED */

      (a3) don't wrap GST_PLUGIN_DEFINE_STATIC with
           #ifndef GST_DISABLE_DEPRECATED at all, in which case the
           compiler will just warn about the old
           _gst_plugin_register_static() function not being declared
           but probably continue.


 (b) is the current gst_plugin_register_static() API ok or is it
     confusing? GST_PLUGIN_DEFINE_STATIC automatically inserts a
     PACKAGE argument into the GstPluginDesc struct, which most people
     will probably forget when converting the arguments to
     GST_PLUGIN_DEFINE_STATIC to a GstPluginDesc, which will result in
     the plugin not getting registered. Three solutions:

      (b1) leave it as it is

      (b2) add a GST_PLUGIN_DESC macro similar to GST_ELEMENT_DETAILS
           which either adds PACKAGE automatically or adds arguments
           for the padding so that the compiler will complain. [yuk]

      (b3) make gst_plugin_register_static() take the stuff in the
           GstPluginDesc struct as arguments rather than a GstPluginDesc
           struct. This is more intuitive, easier to document and the
           compiler will complain about missing arguments.


I'm leaning towards (a3) and (b3).

I'll make a patch as soon as there's a consensus what to do (if anything needs
changing at all).

Opinions?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=510187.