[gst-devel] [gst-cvs] tpm gstreamer: gstreamer/ gstreamer/docs/gst/ gstreamer/gst/ gstreamer/tests/check/gst/

Stefan Kost ensonic at hora-obscura.de
Thu Jan 17 09:09:27 CET 2008

Quoting Tim Müller <t.i.m at zen.co.uk>:

> On Wed, 2008-01-16 at 23:32 +0200, Stefan Kost wrote:
>> any ideas how to handle such changes a bit more graceful. The issue:
>> I build my app against gst-cvs and use disable-deprecated. So if   
>> there is such a
>> change my build fails. So far okay. Old API deprecated, new api there as a
>> replacement - available since 0.10.16. Okay, check for gst-0.10.16   
>> and use new
>> api if we have it. Bang. There is no 0.10.16 available (yet).
> Why not just check for and use the new API, and if someone
> complains about it not building, tell them to cvs update core? Just like
> we do for the plugins modules basically. If you build against CVS and
> use disable-deprecated you'll have to live with the consequences, I
> don't think it's really worth working around that.
It's since 0.10.16 and not I now check for the existence of  
that function. but checking for the nano and defining HAVE_GST_CVS is  
probably better.
The other thing that hit me what that the MACRO was adding PACKAGE and  
when you define the struct yourself and use a ',' in the end instead  
of GST_PADDING_INIT, gcc won't warn about missing initializer, but the  
plugin wont register.
It was also amazing what kind of error mesages gcc gave on the absence  
of the macro definition.

>> Should we only activate the deprecations after bumping the version? How do
>> others handle that? reconfigure all the build-slaves and developer checkouts
>> (remove the disable deprecated). Do I overlook something obvious?
> You could just add an #undef GST_DISABLE_DEPRECATED before the first
> include in the affected source file(s) if you don't want to change over
> to the new API quite yet.

That would work.


>  Cheers
>   -Tim

More information about the gstreamer-devel mailing list