luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-10-31 00:12:19 +01:00
Code Issues Packages Projects Releases Wiki Activity
Files
26c66ab1b9806d097bd1080240435cb37642f141
glib/glib/gversionmacros.h

370 lines
12 KiB
C
Raw Normal View History

Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
/* GLIB - Library of useful routines for C programming
* Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Updated FSF's address
2014-01-23 12:58:29 +01:00
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
*/
/*
* Modified by the GLib Team and others 1997-2000. See the AUTHORS
* file for a list of people on the GLib Team. See the ChangeLog
* files for a list of changes. These files are distributed with
* GLib at ftp://ftp.gtk.org/pub/gtk/.
*/
Move single-include guards inside include guards gcc has optimizations for include guards that only work if they are outermost in the the header. https://bugzilla.gnome.org/show_bug.cgi?id=689810
2012-12-27 23:43:14 -05:00
#ifndef __G_VERSION_MACROS_H__
#define __G_VERSION_MACROS_H__
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#if !defined (__GLIB_H_INSIDE__) && !defined (GLIB_COMPILATION)
#error "Only <glib.h> can be included directly."
#endif
/* Version boundaries checks */
#define G_ENCODE_VERSION(major,minor) ((major) << 16 | (minor) << 8)
/* XXX: Every new stable minor release bump should add a macro here */
/**
* GLIB_VERSION_2_26:
*
* A macro that evaluates to the 2.26 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.32
*/
#define GLIB_VERSION_2_26 (G_ENCODE_VERSION (2, 26))
/**
* GLIB_VERSION_2_28:
*
* A macro that evaluates to the 2.28 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.32
*/
#define GLIB_VERSION_2_28 (G_ENCODE_VERSION (2, 28))
/**
* GLIB_VERSION_2_30:
*
* A macro that evaluates to the 2.30 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.32
*/
#define GLIB_VERSION_2_30 (G_ENCODE_VERSION (2, 30))
/**
* GLIB_VERSION_2_32:
*
* A macro that evaluates to the 2.32 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.32
*/
#define GLIB_VERSION_2_32 (G_ENCODE_VERSION (2, 32))
Add version macros for 2.34 This marks the start of the new development cycle, and opens the window for API additions. https://bugzilla.gnome.org/show_bug.cgi?id=673659
2012-04-09 20:27:24 +02:00
/**
* GLIB_VERSION_2_34:
*
* A macro that evaluates to the 2.34 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.34
*/
#define GLIB_VERSION_2_34 (G_ENCODE_VERSION (2, 34))
Add GLIB_VERSION_2_36 and related
2012-09-05 09:44:24 -04:00
/**
* GLIB_VERSION_2_36:
*
* A macro that evaluates to the 2.36 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.36
*/
#define GLIB_VERSION_2_36 (G_ENCODE_VERSION (2, 36))
Add GLib 2.38 version macros
2013-04-01 16:53:33 -04:00
/**
* GLIB_VERSION_2_38:
*
gversionmacros: fix a typo
2013-04-04 13:15:00 -04:00
* A macro that evaluates to the 2.38 version of GLib, in a format
Add GLib 2.38 version macros
2013-04-01 16:53:33 -04:00
* that can be used by the C pre-processor.
*
gversionmacros: fix a typo
2013-04-04 13:15:00 -04:00
* Since: 2.38
Add GLib 2.38 version macros
2013-04-01 16:53:33 -04:00
*/
#define GLIB_VERSION_2_38 (G_ENCODE_VERSION (2, 38))
Introduce version macros for 2.40
2013-09-23 17:46:58 -04:00
/**
* GLIB_VERSION_2_40:
*
Fix typo in GLIB_VERSION_2_40 docs. https://bugzilla.gnome.org/show_bug.cgi?id=708714
2013-09-25 09:39:20 +02:00
* A macro that evaluates to the 2.40 version of GLib, in a format
Introduce version macros for 2.40
2013-09-23 17:46:58 -04:00
* that can be used by the C pre-processor.
*
* Since: 2.40
*/
#define GLIB_VERSION_2_40 (G_ENCODE_VERSION (2, 40))
Bump version to 2.41.0, add GLIB_VERSION_2_42, etc
2014-03-25 13:20:13 -04:00
/**
* GLIB_VERSION_2_42:
*
* A macro that evaluates to the 2.42 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.42
*/
#define GLIB_VERSION_2_42 (G_ENCODE_VERSION (2, 42))
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
/* evaluates to the current stable version; for development cycles,
* this means the next stable target
*/
#if (GLIB_MINOR_VERSION % 2)
#define GLIB_VERSION_CUR_STABLE (G_ENCODE_VERSION (GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION + 1))
#else
#define GLIB_VERSION_CUR_STABLE (G_ENCODE_VERSION (GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION))
#endif
/* evaluates to the previous stable version */
#if (GLIB_MINOR_VERSION % 2)
#define GLIB_VERSION_PREV_STABLE (G_ENCODE_VERSION (GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION - 1))
#else
#define GLIB_VERSION_PREV_STABLE (G_ENCODE_VERSION (GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION - 2))
#endif
Add version macros for 2.44
2014-09-29 11:39:51 -04:00
/**
* GLIB_VERSION_2_44:
*
* A macro that evaluates to the 2.44 version of GLib, in a format
* that can be used by the C pre-processor.
*
* Since: 2.44
*/
#define GLIB_VERSION_2_44 (G_ENCODE_VERSION (2, 44))
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
/**
* GLIB_VERSION_MIN_REQUIRED:
*
* A macro that should be defined by the user prior to including
* the glib.h header.
* The definition should be one of the predefined GLib version
* macros: %GLIB_VERSION_2_26, %GLIB_VERSION_2_28,...
*
Clarify the GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED docs https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 14:08:22 -04:00
* This macro defines the earliest version of GLib that the package is
* required to be able to compile against.
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
*
Clarify the GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED docs https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 14:08:22 -04:00
* If the compiler is configured to warn about the use of deprecated
* functions, then using functions that were deprecated in version
* %GLIB_VERSION_MIN_REQUIRED or earlier will cause warnings (but
* using functions deprecated in later releases will not).
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
*
* Since: 2.32
*/
Deal with GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED being a "future" value If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined to a future value, we were essentially treating it as GLIB_VERSION_0_0. Fix to treat it as being in the future instead. https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 11:08:23 -04:00
/* If the package sets GLIB_VERSION_MIN_REQUIRED to some future
* GLIB_VERSION_X_Y value that we don't know about, it will compare as
* 0 in preprocessor tests.
*/
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#ifndef GLIB_VERSION_MIN_REQUIRED
version macros: Make MIN_REQUIRED the current stable version So that deprecation warnings will come into effect starting from the stable release, instead of the next.
2012-05-08 15:12:42 +01:00
# define GLIB_VERSION_MIN_REQUIRED (GLIB_VERSION_CUR_STABLE)
Deal with GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED being a "future" value If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined to a future value, we were essentially treating it as GLIB_VERSION_0_0. Fix to treat it as being in the future instead. https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 11:08:23 -04:00
#elif GLIB_VERSION_MIN_REQUIRED == 0
# undef GLIB_VERSION_MIN_REQUIRED
# define GLIB_VERSION_MIN_REQUIRED (GLIB_VERSION_CUR_STABLE + 2)
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
/**
* GLIB_VERSION_MAX_ALLOWED:
*
* A macro that should be defined by the user prior to including
* the glib.h header.
* The definition should be one of the predefined GLib version
* macros: %GLIB_VERSION_2_26, %GLIB_VERSION_2_28,...
*
Clarify the GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED docs https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 14:08:22 -04:00
* This macro defines the latest version of the GLib API that the
* package is allowed to make use of.
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
*
Clarify the GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED docs https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 14:08:22 -04:00
* If the compiler is configured to warn about the use of deprecated
* functions, then using functions added after version
* %GLIB_VERSION_MAX_ALLOWED will cause warnings.
*
* Unless you are using GLIB_CHECK_VERSION() or the like to compile
* different code depending on the GLib version, then this should be
* set to the same value as %GLIB_VERSION_MIN_REQUIRED.
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
*
* Since: 2.32
*/
Deal with GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED being a "future" value If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined to a future value, we were essentially treating it as GLIB_VERSION_0_0. Fix to treat it as being in the future instead. https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 11:08:23 -04:00
#if !defined (GLIB_VERSION_MAX_ALLOWED) || (GLIB_VERSION_MAX_ALLOWED == 0)
# undef GLIB_VERSION_MAX_ALLOWED
# define GLIB_VERSION_MAX_ALLOWED (GLIB_VERSION_CUR_STABLE)
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
/* sanity checks */
Deal with GLIB_VERSION_MIN_REQUIRED/MAX_ALLOWED being a "future" value If GLIB_VERSION_MIN_REQUIRED or GLIB_VERSION_MAX_ALLOWED was defined to a future value, we were essentially treating it as GLIB_VERSION_0_0. Fix to treat it as being in the future instead. https://bugzilla.gnome.org/show_bug.cgi?id=674898
2012-04-26 11:08:23 -04:00
#if GLIB_VERSION_MIN_REQUIRED > GLIB_VERSION_CUR_STABLE
#error "GLIB_VERSION_MIN_REQUIRED must be <= GLIB_VERSION_CUR_STABLE"
#endif
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_MIN_REQUIRED
#error "GLIB_VERSION_MAX_ALLOWED must be >= GLIB_VERSION_MIN_REQUIRED"
#endif
#if GLIB_VERSION_MIN_REQUIRED < GLIB_VERSION_2_26
#error "GLIB_VERSION_MIN_REQUIRED must be >= GLIB_VERSION_2_26"
#endif
Add a 'these are private' note for the version macros
2012-02-27 00:32:13 -05:00
/* These macros are used to mark deprecated functions in GLib headers,
* and thus have to be exposed in installed headers. But please
* do *not* use them in other projects. Instead, use G_DEPRECATED
* or define your own wrappers around it.
*/
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
#define GLIB_AVAILABLE_IN_ALL _GLIB_EXTERN
Add a 'these are private' note for the version macros
2012-02-27 00:32:13 -05:00
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
/* XXX: Every new stable minor release should add a set of macros here */
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_26
# define GLIB_DEPRECATED_IN_2_26 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_26_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_26 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_26_FOR(f) _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_26
# define GLIB_AVAILABLE_IN_2_26 GLIB_UNAVAILABLE(2, 26)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_26 _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_28
# define GLIB_DEPRECATED_IN_2_28 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_28_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_28 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_28_FOR(f) _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_28
# define GLIB_AVAILABLE_IN_2_28 GLIB_UNAVAILABLE(2, 28)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_28 _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_30
# define GLIB_DEPRECATED_IN_2_30 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_30_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_30 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_30_FOR(f) _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_30
# define GLIB_AVAILABLE_IN_2_30 GLIB_UNAVAILABLE(2, 30)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_30 _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_32
# define GLIB_DEPRECATED_IN_2_32 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_32_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_32 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_32_FOR(f) _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_32
# define GLIB_AVAILABLE_IN_2_32 GLIB_UNAVAILABLE(2, 32)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_32 _GLIB_EXTERN
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif
Add version macros for 2.34 This marks the start of the new development cycle, and opens the window for API additions. https://bugzilla.gnome.org/show_bug.cgi?id=673659
2012-04-09 20:27:24 +02:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_34
# define GLIB_DEPRECATED_IN_2_34 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_34_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_34 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_34_FOR(f) _GLIB_EXTERN
Add version macros for 2.34 This marks the start of the new development cycle, and opens the window for API additions. https://bugzilla.gnome.org/show_bug.cgi?id=673659
2012-04-09 20:27:24 +02:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_34
# define GLIB_AVAILABLE_IN_2_34 GLIB_UNAVAILABLE(2, 34)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_34 _GLIB_EXTERN
Add version macros for 2.34 This marks the start of the new development cycle, and opens the window for API additions. https://bugzilla.gnome.org/show_bug.cgi?id=673659
2012-04-09 20:27:24 +02:00
#endif
Add GLIB_VERSION_2_36 and related
2012-09-05 09:44:24 -04:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_36
# define GLIB_DEPRECATED_IN_2_36 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_36_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_DEPRECATED_IN_2_36 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_36_FOR(f) _GLIB_EXTERN
Add GLIB_VERSION_2_36 and related
2012-09-05 09:44:24 -04:00
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_36
# define GLIB_AVAILABLE_IN_2_36 GLIB_UNAVAILABLE(2, 36)
#else
Add a new _GLIB_EXTERN macro for "extern" This macro simply evaluates the "extern" unless it has been explicitly defined to something else. All of the version macros (including the unversioned deprecation markers and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their definition. G_INLINE has also been modified to use _GLIB_EXTERN where appropriate. This macro should never be used outside of the gmacros.h/gversonmacros.h headers. The effect of this patch is that "extern" has now been added to all functions declared in installed headers. Strictly speaking, this is something we should have had all along... GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on non-Windows, instead of "extern" which they were using before. The eventual goal is to use the normal version/deprecation macros on exported variables and drop GLIB_VAR but we need to see how this will work on Windows before we go ahead with that. https://bugzilla.gnome.org/show_bug.cgi?id=688681
2012-12-06 13:37:45 -05:00
# define GLIB_AVAILABLE_IN_2_36 _GLIB_EXTERN
Add GLIB_VERSION_2_36 and related
2012-09-05 09:44:24 -04:00
#endif
Add GLib 2.38 version macros
2013-04-01 16:53:33 -04:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_38
# define GLIB_DEPRECATED_IN_2_38 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_38_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
# define GLIB_DEPRECATED_IN_2_38 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_38_FOR(f) _GLIB_EXTERN
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_38
# define GLIB_AVAILABLE_IN_2_38 GLIB_UNAVAILABLE(2, 38)
#else
# define GLIB_AVAILABLE_IN_2_38 _GLIB_EXTERN
#endif
Introduce version macros for 2.40
2013-09-23 17:46:58 -04:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_40
# define GLIB_DEPRECATED_IN_2_40 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_40_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
# define GLIB_DEPRECATED_IN_2_40 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_40_FOR(f) _GLIB_EXTERN
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_40
# define GLIB_AVAILABLE_IN_2_40 GLIB_UNAVAILABLE(2, 40)
#else
# define GLIB_AVAILABLE_IN_2_40 _GLIB_EXTERN
#endif
Bump version to 2.41.0, add GLIB_VERSION_2_42, etc
2014-03-25 13:20:13 -04:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_42
# define GLIB_DEPRECATED_IN_2_42 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_42_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
# define GLIB_DEPRECATED_IN_2_42 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_42_FOR(f) _GLIB_EXTERN
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_42
# define GLIB_AVAILABLE_IN_2_42 GLIB_UNAVAILABLE(2, 42)
#else
# define GLIB_AVAILABLE_IN_2_42 _GLIB_EXTERN
#endif
Add version macros for 2.44
2014-09-29 11:39:51 -04:00
#if GLIB_VERSION_MIN_REQUIRED >= GLIB_VERSION_2_44
# define GLIB_DEPRECATED_IN_2_44 GLIB_DEPRECATED
# define GLIB_DEPRECATED_IN_2_44_FOR(f) GLIB_DEPRECATED_FOR(f)
#else
# define GLIB_DEPRECATED_IN_2_44 _GLIB_EXTERN
# define GLIB_DEPRECATED_IN_2_44_FOR(f) _GLIB_EXTERN
#endif
#if GLIB_VERSION_MAX_ALLOWED < GLIB_VERSION_2_44
# define GLIB_AVAILABLE_IN_2_44 GLIB_UNAVAILABLE(2, 44)
#else
# define GLIB_AVAILABLE_IN_2_44 _GLIB_EXTERN
#endif
Add flexible API version boundaries 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
2012-02-20 16:20:15 +00:00
#endif /* __G_VERSION_MACROS_H__ */
Reference in New Issue Copy Permalink