Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.
Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.
So, kill G_OS_BEOS.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
