Re: Deprecations

[Mart Raudsepp <leio dustbite net>]

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), if one can even figure out all of the possible macros for them
(e.g, I missed GDK_PIXBUF_DISABLE_DEPRECATED at first)

> > > 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.
> 
> So would upgrading the C compiler (think new gcc and the aliasing
> warnings), or using a different set of headers that produces a warning
> on an obscure architecture.  -Werror is a fine and mighty useful tool
> for development, but a very bad idea for released code.

-Werror certainly doesn't sound like an argument to me. I've stumbled on
enough projects that declare -Werror (and pretty often in stable release
tarballs, at that), which simply fail to compile. They can't possibly
count to all the system differences like unsigned vs signed integer
types coming from system headers, that gcc-4.1 succesfully warns about
and proceeds to error out due to that mighty useful flag that gives
grief.
I find "make >/dev/null" or "make -s" a much better tool to see what
warnings are in the code.

But yes, some maintainers might find -Werror a good tool, but such
maintainers tend to be (or should be) the ones that take all warnings
seriously, and as such would simply get rid of the deprecated functions
usage.

Ultimately it's up to glib/pango/gtk+/etc maintainers, of course.

-- Mart