今年九月,GLib 将发布 2.58 版本。在过去的两个开发周期中发生了一些变化,最显著的是 Meson 构建的改进,这反过来又提高了 GLib 在 Windows、macOS 和 Android 等平台上的可移植性。现在是时候评估 GLib 的当前状态,并强调一些将影响基于 GLib 代码的更改。
- Meson – 感谢 Nirbheek Chauhan 和 Xavier Claessens 的持续努力,Meson 构建一直在不断改进,以至于我们可以开始将其切换为默认构建系统。该计划(如邮件列表中概述的那样)是使用 Meson 发布 GLib 2.58,同时保留树中的 Autotools 构建并使其在发布存档中可用;然后,我们将在下一个开发周期中删除 Autotools 构建,并发布不带 Autotools 支持的 GLib 2.60。非常欢迎 Linux 发行商开始在其构建器中测试 Meson 构建;我们已经将 Meson 构建作为我们的CI流程的一部分运行了一段时间,但更多的曝光将暴露出我们错过的最终回归;此外,如果使用 GCC/Clang/MSVC 以外的不同工具链的人们开始尝试 Meson 构建并报告错误,那就太好了。与此同时,如果您在 macOS 和 Windows 上使用 GLib,我们已经建议您切换到 Meson 来构建 GLib,因为它比 Autotools 更容易且更好地与这些平台集成
- 可靠性和可移植性 – GLib 与 GNOME 的其余部分一起切换到了 GitLab,这意味着能够在GNOME Continuous 构建之外运行持续集成。现在,我们为每次提交和合并请求运行CI在多个工具链、多个构建系统和多个平台上,这大大降低了构建损坏的可能性。我们还提高了测试套件中的代码覆盖率。当然,我们总是可以做得更好;例如,我们没有CImacOS 和 Solaris 系列操作系统的运行器,并且非常感谢为 *BSD 系列提供更多运行器。如果您有空闲的机器和一些带宽可以捐赠,我们已经发布了帮助请求
- *BSD 上的文件监控 – 关于 *BSD 系列,Martin Pieuchot 和 Ting-Wei Lan 对 GIO 中用于文件监控的
kqueue
后端进行了全面改进;新代码更简单、更健壮,并且通过了所有测试 - 使用
posix_spawn()
进行高效的进程启动 — 感谢 Daniel Drake,如果平台的 C 库支持,GLib 现在可以在特定情况下使用posix_spawn()
;与手动调用fork() + exec()
相比,这允许在内核中命中快速路径;当在内存受限的平台上运行时,这些快速路径尤其有益 - 引用计数类型和分配 — GLib 在其许多类型中使用引用计数作为内存管理和垃圾回收机制,但缺乏公共 API 来允许其他人在其自己的数据结构中实现相同的语义;这导致了大量的复制粘贴和重新实现,并且通常会导致诸如饱和和线程安全方面未定义的行为。GLib 2.58 具有
grefcount
和gatomicrefcount
类型及其 API,以减少这种重复。此外,借鉴 Rust 等其他语言的经验,GLib 提供了一种通过添加底层 API 来为内存分配添加引用计数语义的方法,该 API 允许您分配没有引用计数字段的结构,并自动向其添加引用计数语义 - 弃用 – 在上一个开发周期中,一些软弃用已变为真正的弃用
-
- 在我们引入实例私有数据宏五年后,
g_type_class_add_private()
终于被弃用了;如果您仍在类初始化中使用该函数,请切换到G_DEFINE_TYPE_WITH_PRIVATE
或G_ADD_PRIVATE
g_main_context_wait()
已正式弃用,但您应该已经看到有关其使用的运行时警告- GLib 提供的 GTest 工具
gtester
已弃用;如果您正在使用 Autotools,则应使用TAPAutomake 附带的工具
- 在我们引入实例私有数据宏五年后,
-
在本周期中,感谢 Philip Withnall 不懈的努力,GLib 中有很多贡献;他在审查补丁、分类错误和实施项目开发过程中的变更方面发挥了重要作用。切换到 GitLab 也改进了贡献流程,更多开发人员打开了合并请求
2.54.0..c182cd68
: 来自 143 位开发人员的 968 个变更集,高于 2.53 开发周期中的 412 个变更集和 68 位开发人员- 总共添加了31851 行,删除了 27976 行(增量:+3875)
拥有最多变更集的开发人员 | ||
---|---|---|
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% |
请务必使用 GLib 2.57.2 测试您的代码,这是 2.58.0 稳定版本的下一个开发快照。
如果 gtester 已弃用,而 TAP 依赖于 autotools,那么推荐的测试框架是什么?
@Martin:gtester 只是测试工具——启动测试并收集结果的东西:您仍然应该使用 GTest 作为测试 API。您应该使用 Autotools 提供的 TAP 工具或 Meson 提供的测试对象,而不是将 gtester 作为测试套件的一部分。请参阅文档:https://developer.gnome.org/glib/unstable/glib-Testing.html
在 CentOS 6.6 Linux 机器上尝试构建 glib 2.58.1 几个小时了。这台机器是 32 位的,但有当前的 i686 库,Firefox 60.2.1 可以运行,Gnome 也可以正常工作等等。但 glib 2.58.1 的构建崩溃了。运行 ./autogen.sh 会导致 configure.ac 在第一个 AC_DEFINE 中崩溃,并显示“configure.ac:88: 错误,可能未定义的宏:AC_DEFINE 如果此标记和其他标记是合法的,请使用 m4_pattern_allow。”
这是一个常见的废纸篓错误响应,通常意味着未安装 pkg-config 或 libtools,或者 autoconf 的版本不足。这里不是这种情况。此构建失败意味着我被卡在 glib-2.28.8。
请允许我请求;如果您要制作软件,那么至少请包含像我这样处于边缘的人们可能希望使用的构建说明。我今晚才听说“meson”。(哦,天哪,又要学习另一个构建系统了……)。
基本上,我现在已经花了 *几个小时* 试图排除这个损坏的构建的故障,并且谷歌搜索并阅读了很多可能过时的材料,这些材料毫无用处。
请注意,如果我们没有可用的构建配置,并且没有人包含用户可以遵循的构建说明(请注意,不仅仅是傲慢的“RTFM ...”——就像 autoconf 错误消息基本上是...),那么每个人的努力都只是浪费。我*已经*陷入困境,试图让一些软件工作,在最后,我似乎已经达到了 glib-2.58 的要求。但是它无法构建。我能找到的所有文档以及我所做的关于依赖项的版本检查都表明这应该可以工作。但我所得到的基本上是一个 autoconf/autotools 错误消息,表明宏 AC_DEFINE 不起作用。
我刚刚安装了“autoconf-archive”,并且一切似乎都在那里。并且工具链的所有组件似乎都是最新的,或者至少在规定的规范内。
为了检查,我 cd 到 glib-2.28.0 目录,并运行 ./autogen.sh,它运行良好,创建了配置,然后运行它,最后为我提供了一条有用的消息,说:“现在键入 'make' 来编译 Glib”。
但我们似乎在 glib-2.58.1 中遇到的只是一个构建失败的问题。而且看起来它会毁掉我的项目,因为 glib(一个核心组件)似乎处于这个深坑的最底部。
这真是太可惜了。:(
– MCL