[prev in list] [next in list] [prev in thread] [next in thread]
List: gnome-devel-list
Subject: Re: GNOME_CORE_API_ONLY
From: Mike Touloumtzis <miket () geoworks ! com>
Date: 1999-07-31 4:11:40
Message-ID: 19990730211140.P1981 () sarcastro ! geoworks ! com
[Download RAW message or body]
Hi Havoc,
Maybe you could have both
#ifdef GNOME_DEPRECATED_API
and
#ifdef GNOME_EXPERIMENTAL_API
so that developers can preserve compatibility with
deprecated features (at least temporarily) without adding
in experimental APIs. This further reduces the chances
of a flag day caused by an API change.
miket
On Thu, Jul 29, 1999 at 08:36:17PM -0700, Havoc Pennington wrote:
>
> Hi,
>
> I propose that in future 1.0.x/2.0 gnome-libs releases we allow users to
> define a debugging symbol GNOME_CORE_API_ONLY. With this defined,
> declarations for strongly deprecated or experimental features will not
> appear in the gnome-libs headers.
>
> For example, in libgnomeui.h we might have:
>
> #ifndef GNOME_CORE_API_ONLY
> #include "gtk-ted.h"
> #endif
>
> because GtkTed is deprecated, or in gnome-canvas.h we might have:
>
> #ifndef GNOME_CORE_API_ONLY
> GnomeCanvas* gnome_canvas_new_aa();
> #endif
>
> because the AA canvas is experimental.
>
> The purpose of this is to allow people to easily "clean" their apps and be
> sure they are only using the stable, debugged, non-deprecated features.
>
> This is intended for debugging only, so we don't commit to source compat
> with this turned on - the whole point is that it *isn't* source compatible
> so you can detect the bad features you're using.
>
> Does it sound like a nice feature to have? If so I'll implement it
> in the near future. But I may have overlooked some problems.
>
> Havoc
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic