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

[Stefan Kost]

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 0.10.15.1 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 0.10.15.1. 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.

Stefan

>
>  Cheers
>   -Tim
>
>
>