Re: -DFOO_DISABLE_DEPRECATED -vs -lfoo-compat

[George <jirka 5z com>]

On Wed, Aug 29, 2001 at 06:36:08PM -0400, Owen Taylor wrote:
> Michael Meeks <michael ximian com> writes:
> > On 27 Aug 2001, Owen Taylor wrote:
> > > Actually just because GTK+ does it _is_ a good reason to do it. Even
> > > if it was a bad idea to do it that way, it's a lot easier to explain
> > > people the operation of FOO_DISABLE_DEPRECATED and FOO_ENABLE_COMPAT
> > > _once_ than to explain a different system for each library.
> > 
> >         Hmm, but wait - I have no idea how FOO_DISABLE vs. ENABLE work,
> > which one is master, which is slave, where I should define them - as a
> > compile flag to gcc ? with ulgy #defines in my source code before gtk
> > includes ... etc. I see the argument for homogeneity, it just doesn't seem
> > good to me.
> 
>  #define GTK_ENABLE_BROKEN   
>  
>     Include functionality in GTK that is known to not work properly
>     and is not supported, but is provided to help porting legacy
>     programs
> 
>  #define GTK_DISABLE_DREPRECATED
> 
>     Do not include functionality that will be removed from GTK
>     in future versions of GTK.
> 
> >From this, I'm sure that the meaning of GLIB_DISABLE_DEPRECATED,
> GDK_ENABLE_BROKEN are clear, as would be GNOME_DISABLE_DEPRECATED.

Not to mention that

1) if we don't use the above policy we do have to explain two policies,
because not linking with libgnome1-compat doesn't mean that you're killing
the gtk compat stuff.

2) Even martin's so called 'frozen' version includes the use of
GNOME_EXCLUDE_DEPRECATED (another name for GNOME_DISABLE_DEPRECATED).
So we have to explain both even if the person is just trying to deal
with libgnome.

(Of course the above two reasons are extra to all the other advantages
of the _DISABLE_DEPRECATED approach)

George

-- 
George <jirka 5z com>
   Computers are useless. They can only give you answers.
                       -- Pablo Picasso