[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/

[Tim Müller]

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.
> ...
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins-base/gst-libs/gst/rtp/gstbasertpdepayload.h.diff?r1=1.20&r2=1.21

I wonder whether it's really a good idea to use GST_REMOVE_DEPRECATED in
public header files, since it breaks ABI.

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.

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.

 Cheers
  -Tim