[gst-devel] [gst-cvs] ensonic gst-plugins-base: gst-plugins-base/ gst-plugins-base/docs/libs/ gst-plugins-base/gst-libs/gst/audio/ gst-plugins-base/gst-libs/gst/interfaces/ gst-plugins-base/gst-libs/gst/rtp/ gst-plugins-base/gst-libs/gst/sdp/
ensonic at hora-obscura.de
Fri Nov 2 20:03:00 CET 2007
Tim Müller schrieb:
> On Tue, 2007-10-30 at 13:32 -0700, ensonic at kemper.freedesktop.org wrote:
>> CVS Root: /cvs/gstreamer
>> Module: gst-plugins-base
>> Changes by: ensonic
>> Date: Tue Oct 30 2007 20:32:28 UTC
>> Log message:
>> * docs/libs/gst-plugins-base-libs-sections.txt:
>> * gst-libs/gst/audio/gstaudiofilter.h:
>> * gst-libs/gst/interfaces/mixer.h:
>> * gst-libs/gst/rtp/gstbasertpdepayload.c:
>> * gst-libs/gst/rtp/gstbasertpdepayload.h:
>> * gst-libs/gst/sdp/gstsdpmessage.c:
>> Fix the docs according to what gtk-doc complained about.
> I wonder whether it's really a good idea to use GST_REMOVE_DEPRECATED in
> public header files, since it breaks ABI.
I though it is quite clear. This is from gstreamer/configure.ac:
# GST_DISABLE_DEPRECATED: hide the visibility of deprecated
# functionality from the API that gstreamer uses
# GST_REMOVE_DEPRECATED: don't compile deprecated functionality (breaks ABI)
So people that actually use GST_REMOVE_DEPRECATED should be well aware that its
breaks binary compatibility. But then gstreamer is used in environment where you
have that under control and imho its a nice feature to be able to leave out
cruft with just one additional flag.
I mean even users on a distro like gentoo could use it, as they can recompile
their whole system if they want (not that it makes a lot sense there).
> So far we've only been using GST_REMOVE_DEPRECATED in .c files to remove
> deprecated functions completely from our lib and guarded the declaration
> of those functions with GST_DISABLE_DEPRECATED.
> What we've done in public headers last time this issue came up is use
> GST_DISABLE_DEPRECATED and then put differently-named dummy fields in
> the #else bracket, so code compiled with DISABLE_DEPRECATED couldn't use
> deprecated structure members any longer, but binary compatibility would
> still be maintained. See
> gst-plugins-base/gst-libs/gst/interfaces/mixer.h for an example.
For GST_DISABLE_DEPRECATED a dummy approach makes sense. But
GST_REMOVE_DEPRECATED means remove. So in theory we need:
/* this value can be modified by the child if needed, deprecated */
(hopully I have not mixed up the neagtions).
> I can see that there are reasons for wanting to remove those fields
> completely (ie. save a few bytes), but I wonder if it's not more
> desirable to maintain ABI/structure sizes, given that derived objects
> may sit in different modules.
Good that you brought it up. Lets decide and fix.
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel