GLIB_VERSION_MAX_ALLOWED in your
meson.build to avoid deprecation warnings you don’t care about, or accidentally using GLib APIs which are newer than you want to use. You can add this to your library by copying
gversionmacros.h and using its macros on public APIs in your header files.
With every new stable release, GLib adds and/or deprecates public API. If you are building a project against GLib, you probably don’t want to use the new APIs until you can reliably depend on a new enough version of GLib. Similarly, you want to be able to continue using the newly-deprecated APIs until you can reliably depend on the version of GLib which deprecated them.
In both cases, the alternative is for your project to add conditional compilation blocks which use some GLib symbols if building against the new version of GLib, and others if building against the old version. That’s lots of work, and no fun.
So to prevent projects using GLib APIs which are outside the range of GLib versions which those projects are tested to build and work against, GLib can emit deprecation warnings at compile time if APIs which are too new – or too old – are used.
You can enable this by defining
GLIB_VERSION_MAX_ALLOWED in your build environment. With Meson, add the following to your top-level
meson.build, typically just after you check for the GLib dependency using
add_project_arguments( '-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_46', '-DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_66', language: 'c')
GLIB_VERSION_x symbols are provided by GLib, and there’s one for each stable release series. You can also use
GLIB_VERSION_PREV_STABLE to refer to the stable version of the copy of GLib you’re building against.
If undefined, both symbols default to the current stable version, meaning you get all new APIs and all deprecation warnings by default. This is good for keeping up to date with developments in GLib, but not so good if you are targeting an older distribution and don’t want to see all the latest deprecation warnings.
None of this is new; this blog post is your periodic reminder that this versioning functionality exists and you may benefit from using it.
Add this to your library too
It’s easy enough to add to other libraries, and should be useful in situations where your library is unlikely to break API for the foreseeable future, but could add or deprecate API with every release.
Simply copy and adapt
gversionmacros.h, and use its macros against every symbol in a public header. You can use them for functions, types, macros and enums.
The downside is that you will need to update the version macros header for each new version of your library, to add macros for the new version. There’s no way round this within the header file, as C macros may not define additional macros. It may be possible to generate the header using an external script from Meson, though, if someone wants to automate it.