Next September, GLib will hit version 2.58. There have been a few changes during the past two development cycles, most notably the improvement of the Meson build, which in turn led to an improved portability of GLib to platforms such as Windows, macOS, and Android. It is time to take stock of the current status of GLib, and to highlight some of the changes that will impact GLib-based code.
- Meson – Thanks to the ongoing work of Nirbheek Chauhan and Xavier Claessens, the Meson build has been constantly improving, to the point that we can start switching to it as the default build system. The plan—as outlined on the mailing list—is to release GLib 2.58 using Meson, while keeping the Autotools build in tree and available in the release archive; then, we’ll drop the Autotools build during the following development cycle, and release GLib 2.60 without Autotools support. Linux distributors are very much welcome to start testing the Meson build in their builders; we’ve been running the Meson build as part of our CI process for a while, now, but more exposure will bring out eventual regressions that we missed; additionally, it would be stellar if people with different toolchains than GCC/Clang/MSVC would start trying the Meson build and report bugs. In the meantime, if you’re using GLib on macOS and Windows, we already recommend you switch to Meson to build GLib, as it’s easier and better integrated with those platforms than Autotools
- Reliability and portability – GLib switched to GitLab alongside the rest of GNOME, which meant being able to run continuous integration outside of the GNOME Continuous builds. Now we run CI on multiple toolchains, multiple build systems, and multiple platforms for every commit and merge request, which significantly reduces the chances of a broken build. We’ve also improved the code coverage in the test suite. Of course, we could always do better; for instance, we don’t have a CI runner for macOS and the Solaris family of OSes, and more runners for the *BSD family would be greatly appreciated. We’ve issued a call for help, if you have a spare machine and some bandwidth that you can donate
- File monitoring on *BSD – Apropos the *BSD family, the
kqueuebackend for file monitoring in GIO has been completely overhauled by Martin Pieuchot and Ting-Wei Lan; the new code is simpler, more robust, and passes all the tests - Use
posix_spawn()for efficient process launching — Thanks to Daniel Drake, GLib now can useposix_spawn()under specific circumstances, if the platform’s C library supports it; this allows hitting fast paths in the kernel, compared to manually callingfork() + exec(); those fast paths are especially beneficial when running on memory constrained platforms - Reference counting types and allocations — GLib uses reference counting as a memory management and garbage collection mechanism in many of its types, but lacks the public API to allow other people to implement the same semantics in their own data structures; this leads to much copy-pasting and re-implementations, and typically to things like undefined behavior when it comes to saturation and thread safety. GLib 2.58 has a
grefcountand agatomicrefcounttypes, alongside their API, to reduce this duplication. Additionally, taking a cue from other languages like Rust, GLib provides a way to add reference counting semantics on memory allocations, by adding a low level API that allows you to allocate structures that do not have a reference count field, and automatically add reference counting semantics to them - Deprecations – A few soft deprecations have become real deprecations in this last development cycle:
-
g_type_class_add_private()has finally been deprecated, five years after we introduced the instance private data macros; if you’re still using that function in your class initialization, please switch toG_DEFINE_TYPE_WITH_PRIVATEorG_ADD_PRIVATEg_main_context_wait()is officially deprecated, but you should have already seen run time warnings about its usegtester, the GTest harness provided by GLib, is deprecated; if you’re using Autotools, you should use the TAP harness that comes with Automake
-
There have been lots of contributions in GLib, in this past cycle, thanks to the tireless efforts of Philip Withnall; he’s been instrumental in reviewing patches, triaging bugs, and implementing changes in the development process of the project. The switch over to GitLab has also improved the contribution process, with many more developers opening merge requests:
2.54.0..c182cd68: 968 changesets from 143 developers, up from 412 changesets and 68 developers during the 2.53 development cycle- A total of 31851 lines added, 27976 removed (delta: +3875)
| Developers with the most changesets | ||
|---|---|---|
| Philip Withnall | 303 | 31.3% |
| Xavier Claessens | 79 | 8.2% |
| Emmanuele Bassi | 69 | 7.1% |
| Christoph Reiter | 42 | 4.3% |
| Ting-Wei Lan | 21 | 2.2% |
| Chun-wei Fan | 21 | 2.2% |
| Nirbheek Chauhan | 21 | 2.2% |
| Ondrej Holy | 20 | 2.1% |
| Руслан Ижбулатов | 20 | 2.1% |
| Mikhail Zabaluev | 20 | 2.1% |
| Simon McVittie | 15 | 1.5% |
| Matthias Clasen | 14 | 1.4% |
| Christian Hergert | 13 | 1.3% |
| Iñigo Martínez | 12 | 1.2% |
| Bastien Nocera | 10 | 1.0% |
| Rafal Luzynski | 9 | 0.9% |
| Michael Catanzaro | 9 | 0.9% |
| Will Thompson | 8 | 0.8% |
| Allison Lortie | 8 | 0.8% |
| Daniel Boles | 8 | 0.8% |
Make sure to test your code with GLib 2.57.2, the next development snapshot towards the 2.58.0 stable release.