On Thu, 27 Apr 2006 10:30:12 -0400 Owen Taylor <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-04-26 at 09:22 +0100, Ross Burton wrote: > > Hi, > > > > 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? At the moment it's very black and white, and > > I think deprecation functions need a grey... > > I think muddling the deprecation system like this is a mistake. > > Say, I'm a developer working on an app that is supposed to work with > GTK+-2.6 and newer, so I develop and compile with GTK+-2.6. > > I have a user who takes one of my releases, and compiles it with > GTK+-2.10 ... they get 20 zillion warnings, and will have little > chance of seeing if something *actually* went wrong with the > compilation. > > They can't even send me a patch to fix these warnings, because > the facilities that caused the functions to be deprecated may > not exist in GTK+-2.6. > > G_GNUC_DEPRECATED is certainly better than what we do know in one > way ... it produces warnings *without* producing miscompilations; > but I don't think there is any real way to take advantage of it > within our current deprecation system without a ton of extra > typing and complexity. Wouldn't it be possible to let the user choose which APIs should be marked with G_GNUC_DEPRECATED when compiling their applications? If the application requires GTK+-2.6, only APIs deprecated in that release would be marked deprecated. Let the user define something like GTK_OLDEST_SUPPORTED_VERSION (which would default to 2.0) and have macros like GTK_DEPRECATED_IN_VERSION(version) for the APIs (perhaps it could warn about APIs newer than the oldest version supposed to be supported as well). I don't know if this would be too complicated, just an idea. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list