On Thu, 27 Apr 2006, Owen Taylor wrote: > On Thu, 2006-04-27 at 01:22 +0300, Mart Raudsepp wrote: > > On Wed, 2006-04-26 at 21:23 +0100, Ross Burton wrote: > > > On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote: > > > > > Would it make sense to mark all of the deprecated API in GLib and GTK+ > > > > > with G_GNUC_DEPRECATED, so that people who are not using the > > > > > DISABLE_DEPRECATED macros still get warned that they are using > > > > > deprecated functions? > > > > Yes, pretty please. > > I'm trying to nuke out all uses of deprecated functions, but declaring > > all the *_DISABLE_DEPRECATED macros is a bit rough still (I can't test > > on all of the combinations of systems the thing is supposed to not error > > out) > > *_DISABLE_DEPRECATED is a tool for developers / for you; you should > never ship like that, because *any* function may be deprecated in a > future version and you have no control over that. > > Add a --configure switch that turns on *_DISABLE_DEPRECATED, configure > your on compilations that way, fix all the resulting problems, but there > is no benefit to shipping that way... a deprecation that one of your > users sees but you don't is a deprecation you can't fix, because you > aren't using a new enough version of GTK+ to have the replacement.
What we are doing in Pango and Gtk+ right now is to enable G_DISABLE_DEPRECATED if and only if the major.minor version of the available glib version is the same as the one we require. I also like if there was a way to detect when the required version of a module (glib and Gtk+ mainly) should be increased in an application. But that requires marking all the API with macros and version number that I know is not going to happen... > Owen --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list