On Wed, 2006-04-26 at 18:19 -0400, Behdad Esfahbod wrote: > On Wed, 26 Apr 2006, David Hampton 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... > > > > That would break any project that compiles code using the -Werror flag. > > Other than already explained and other reasons, if somebody cares > enough about warnings to use -Werror, they are probably > interested in getting rid of the deprecated API too.
I didn't say that developers using -Werror don't care about removing deprecated functions. Here's my problem. GnuCash currently compiles cleanly using gcc-4.1 and -Werror on both i386 and amd64 systems, so Ross's issue of aliasing warnings has already been handled. If you add the G_GNUC_DEPRECATED tag to these functions as proposed, gnucash will stop compiling with 338 or so error messages. No one is going to complain to you when this happens, but they are going turn to me and the other GnuCash developers. I know there are users compiling GnuCash on RedHat Rawhide, so the lead time between this proposed change being implemented and the first complaint will be pretty short. I am in the slow process of eliminating all deprecated functions from GnuCash, and all the glib deprecated functions have already been removed. However, the code base is huge and we're already into string freeze for our long overdue 2.0 release, so I can no longer make architectural changes to the code. Once 2.0 is released I can continue removing deprecated functions. I can't imagine GnuCash the only application in this position. David P.S. Please don't get me wrong. I'm not saying that this is a bad idea, only that its unconditional application is a bad idea. If it was a conditional flag that could be enabled or disabled I would welcome it. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
