how to guard deprecated signals
|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
 |
how to guard deprecated signals
by Stefan Kost
::
Rate this Message:
hi,
just found a property in gstreamer that is deprecated. Thus I get this from gtk-doc: WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the inline comments but no deprecation guards were found around the declaration. (See the --deprecated-guards option for gtkdoc-scan.) Now I wonder where one should/could add deprecation guards? #ifndef GST_DISABLE_DEPRECATED #endif gtk-doc expects them in the headers. Stefan _______________________________________________ gtk-doc-list mailing list gtk-doc-list@... http://mail.gnome.org/mailman/listinfo/gtk-doc-list |
|
|
Re: how to guard deprecated signals
by David Nečas (Yeti)-2
::
Rate this Message:
On Tue, Oct 30, 2007 at 10:23:59PM +0200, Stefan Kost wrote:
> just found a property in gstreamer that is deprecated. Thus I get this from gtk-doc: > > WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the inline comments > but no deprecation guards were found around the declaration. > (See the --deprecated-guards option for gtkdoc-scan.) > > Now I wonder where one should/could add deprecation guards? > #ifndef GST_DISABLE_DEPRECATED > #endif > > gtk-doc expects them in the headers. The warning is wrong. First, I think marking deprecated symbols with preprocessor conditionals in the header files is a matter of coding style of a particular project and should not be mandatory. But more to the point, it is impossible to make something inaccessible with an #ifdef when it's registered run-time by the library (which, of course, has a completely different idea of what is deprecated and what is not than the library version you compiled the app with, and madness lies in the direction of run-time deprecation handling as deprecation is nothing else than a weak form of backward compatibility breach). So, for signals and properties, you have to trust the documentation and not emit such warnings. Yeti -- http://gwyddion.net/ _______________________________________________ gtk-doc-list mailing list gtk-doc-list@... http://mail.gnome.org/mailman/listinfo/gtk-doc-list |
|
|
Re: how to guard deprecated signals
by Stefan Kost
::
Rate this Message:
Hi,
Quoting "David Ne?as (Yeti)" <yeti@...>: > On Tue, Oct 30, 2007 at 10:23:59PM +0200, Stefan Kost wrote: >> just found a property in gstreamer that is deprecated. Thus I get >> this from gtk-doc: >> >> WARNING: GstBaseRTPDepayload::queue-delay is deprecated in the >> inline comments >> but no deprecation guards were found around the declaration. >> (See the --deprecated-guards option for gtkdoc-scan.) >> >> Now I wonder where one should/could add deprecation guards? >> #ifndef GST_DISABLE_DEPRECATED >> #endif >> >> gtk-doc expects them in the headers. > > The warning is wrong. First, I think marking deprecated > symbols with preprocessor conditionals in the header files > is a matter of coding style of a particular project and > should not be mandatory. > > But more to the point, it is impossible to make something > inaccessible with an #ifdef when it's registered run-time by > the library (which, of course, has a completely different > idea of what is deprecated and what is not than the library > version you compiled the app with, and madness lies in the > direction of run-time deprecation handling as deprecation is > nothing else than a weak form of backward compatibility > breach). > > So, for signals and properties, you have to trust the > documentation and not emit such warnings. Right. Fixed in SVN Stefan > > Yeti > > -- > http://gwyddion.net/ > _______________________________________________ > gtk-doc-list mailing list > gtk-doc-list@... > http://mail.gnome.org/mailman/listinfo/gtk-doc-list > _______________________________________________ gtk-doc-list mailing list gtk-doc-list@... http://mail.gnome.org/mailman/listinfo/gtk-doc-list |
| Free embeddable forum powered by Nabble | Forum Help |
