Re: -DFOO_DISABLE_DEPRECATED -vs -lfoo-compat

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
>     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,

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
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 <jirka 5z com>
   Computers are useless. They can only give you answers.
                       -- Pablo Picasso

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]