Re: Dealing with *_DISABLE_DEPRECATED now and in the future

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-10-27 at 07:53, Jeff Waugh wrote:
> Hey everyone (and Owen),
> 
> It is unlikely that we can put out a sane 2.5 tarball release soon due to
> breakage between unported 2.4-series modules building against GTK+ 2.3 with
> deprecated widgets. This is due to tarballs using -D*_DISABLE_DEPRECATED.
> 
> There have been a number of suggestions as to how to fix this including:
> 
>   - Don't ever build tarballs with *_DISABLE_DEPRECATED flags.

Tarballs should never be released with *_DISABLE_DEPRECATED. 

DISABLE_DEPRECATED is a developer tool; it's meant to tell you what is
disabled so you can fix it. It doesn't add anything to people
testing software to have it compiled with DISABLE_DEPRECATED.

If you release a tarball with DISABLE_DEPRECATED you are *lucky* if
it fails in a obvious way. Subtle miscompilations are also possible.

>   - Don't release unstable platform or desktop tarballs with *_D_D flags
>     (some argue that platform and maybe even desktop modules should only
>     ever be built against their intended platform).

The argument is even strong for *stable* platform and desktop tarballs.

>   - Use versioned *_D_D flags.

This would make things much more complicated.

> Obviously this has come up already in GTK+ and some GNOME circles, but we
> need to resolve it for 2.5 very soon, or we won't be able to do regular
> tarball releases for testing (arguments about usefulness aside).
> 
> As it stands, we will need to build fresh, fixed tarballs for *every* module
> in the 2.5 series before we can do a complete release. It would make sense
> to hold off until we have a good solution in place, however... So, we need
> to work that out quickly! :-)
> 
> (Owen, just wanted to bring this conversation up in GNOME-land to see how we
> should be dealing with this, and what your thoughts are.)

Versioned *DISABLE_DEPRECATED flags would have to be brought up on 
gtk-devel-list, if we wanted them, but I don't think they are a good
idea or needed.

We probably should set come up with a standard configure option name
for turning on deprecation warnings, and it might make sense to put
that option in the default autogen.sh configure flags.

Untested autoconf and automake fragments:

AC_ARG_ENABLE(deprecations,
              [AC_HELP_STRING([--enable-deprecations],
                              [warn about deprecated usages [default=no]])],,
              [enable_deprecations=no])

AM_CONDITIONAL(ENABLE_DEPRECATIONS, test "x$enable_deprecations" = xyes)


if ENABLE_DEPRECATIONS
INCLUDES += -DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED
fi

Regards,
						Owen