GStreamer-devel

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

Classic

List

Threaded

4 messages Options

Stefan Sauer

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

hi,

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

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?

Stefan

[hidden email] schrieb:

> CVS Root: /cvs/gstreamer
> Module: gstreamer
> Changes by: tpm
> Date: Wed Jan 09 2008 18:23:53 UTC
>
> Log message:
> * docs/gst/gstreamer-sections.txt:
> * gst/gst.c: (init_post):
> * gst/gstplugin.c: (_gst_plugin_register_static),
> (gst_plugin_register_static), (_gst_plugin_initialize),
> (gst_plugin_register_func):
> * gst/gstplugin.h: (GST_PLUGIN_DEFINE_STATIC):
> API: add gst_plugin_register_static() and deprecate
> GST_PLUGIN_DEFINE_STATIC, since it's not portable
> (#498924).
> Also, in _gst_plugin_register_static(), make sure to call
> g_thread_init() before calling GLib functions such as
> g_list_append() if we're not initialised yet, since that
> may lead to random crashes with older GSlice/GLib versions.
> * tests/check/gst/gstplugin.c:
> Adapt unit test to above changes.
>
> Modified files:
> . : ChangeLog
> docs/gst : gstreamer-sections.txt
> gst : gst.c gstplugin.c gstplugin.h
> tests/check/gst : gstplugin.c
>
> Links:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/ChangeLog.diff?r1=1.3620&r2=1.3621
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/docs/gst/gstreamer-sections.txt.diff?r1=1.320&r2=1.321
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gst.c.diff?r1=1.249&r2=1.250
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gstplugin.c.diff?r1=1.181&r2=1.182
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/gst/gstplugin.h.diff?r1=1.70&r2=1.71
> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/tests/check/gst/gstplugin.c.diff?r1=1.11&r2=1.12
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> gstreamer-cvs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-cvs

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tim-Philipp Müller-2

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

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.

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

Cheers
-Tim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

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

Quoting Tim Müller <[hidden email]>:

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

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

In reply to this post by Tim-Philipp Müller-2

hi again,

Quoting Tim Müller <[hidden email]>:

I think the main issues is that when

#ifndef GST_DISABLE_DEPRECATED
#endif
is used on a function prototype one gets a warning, but the build goes
on (unless -Werror). If you use that on a macro, the build fails
always. The compile sees something like a function call (without a
prototype) outside a function. So what we should probably do is the
attached patch.

Then one gets:
cc1: warnings being treated as errors
sink-bin.c:902: warning: 'bt_sink_bin_plugin_init' defined but not used
sink-bin.c:920: warning:
'_gst_plugin_static_init__bt_sink_bin_plugin_init' defined but not used

instead of:
sink-bin.c:921: error: expected declaration specifiers or '...' before
'(' token
sink-bin.c:922: error: expected declaration specifiers or '...' before
'(' token
sink-bin.c:923: error: expected declaration specifiers or '...' before
string constant
sink-bin.c:924: error: expected declaration specifiers or '...' before
string constant
sink-bin.c:925: error: expected declaration specifiers or '...' before
'bt_sink_bin_plugin_init'
sink-bin.c:925: error: expected declaration specifiers or '...' before
string constant
sink-bin.c:925: error: expected declaration specifiers or '...' before
string constant
sink-bin.c:925: error: expected declaration specifiers or '...' before
string constant
sink-bin.c:925: error: expected declaration specifiers or '...' before
string constant
cc1: warnings being treated as errors
sink-bin.c:926: warning: data definition has no type or storage class
sink-bin.c:926: warning: type defaults to 'int' in declaration of
'GST_PLUGIN_DEFINE_STATIC'

Stefan

>
>
>> 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.
>
> Cheers
> -Tim
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

plugin_static_deprecated-01.patch (1K) Download Attachment