Chez Scheme 在 Debian 中的现状

# Chez Scheme 在 Debian 中的现状 来源：https://weinholt.se/articles/state-of-chezscheme-in-debian/ 我已经将 Chez Scheme 10.4.0 上传到 Debian unstable。距 Debian 中出现新版本 Chez Scheme 已有几年时间，这都怪我。😅 根据[构建日志](https://buildd.debian.org/status/logs.php?pkg=chezscheme)，新版本在所有架构上都能正常构建。 如果你没注意到，Chez Scheme 从 Racket 团队那里获得了新的活力，并在几年前获得了可移植字节码支持。因此，对于那些没有原生后端的架构，Chez 改为生成可移植字节码。 m68k 和 hppa 曾有一个问题：它们有时会为可移植字节码得到错误的字节序，这可能取决于哪个 buildd 接管的构建。但现在应该已经修复，因为 `debian/rules` 会根据 Debian 的构建变量来构造机器类型。 ## Debian Scheme Dream Team 我将这个包移交给了 Debian Scheme Dream Team！所以现在有更多人可以帮助维护它。团队最近规模有所壮大，这真是令人高兴。我希望我们能一起让 Scheme 在 Debian 中成为更强大的语言。 ## 交叉编译曾出现问题 我在 [Salsa 流水线](https://salsa.debian.org/scheme-team/chezscheme/-/pipelines)中启用了从 amd64 到 arm64 的交叉编译，发现它实际上已损坏！问题在于交叉编译会启动一个次要构建，而我们的一些构建参数在该构建中缺失了。因此，次要构建找不到 zuo，并且还使用了错误的 C 编译器。这个问题已通过修补 [build.zuo](https://salsa.debian.org/scheme-team/chezscheme/-/blob/50b2d295360850430ae8124b5ff464f73b98c010/debian/patches/0003-build.zuo-passes-through-ZUO-ZLIB-etc-for-cross-comp.patch) 解决。这个补丁应该提交到上游。 ## 未来的工作 `chezscheme-dev` 包其实我没有亲自测试过。它提供了 `libkernel.a`、`main.o` 和 `scheme.h`。也许能用，但从来没有人说过不行。:) 然后还有可移植字节码！在软件源中是可以对它们进行去重的。它们可以构建为 `Architecture: all` 的包并被复用。例如，现在 sparc64 和 ppc64 都会构建多线程 64 位大端字节码，所以这些字节码在软件源中至少存在两份。 ## 可重现构建 最后但同样重要的是，Chez Scheme 的构建目前[不可重现](https://github.com/cisco/ChezScheme/issues/585)。这正成为一个真正的问题，因为 Debian 的发布团队已[强制要求可重现构建](https://weinholt.se/articles/state-of-chezscheme-in-debian/_https://lists.debian.org/debian-devel-announce/2026/05/msg00001.html)。如果不修复这个问题，Chez Scheme 将无法进入未来的 Debian 版本。幸运的是，这个问题似乎是可以修复的。问题的根源在于使用了唯一标识符来支持分离编译。如果有人对背景感兴趣，可以查阅 Oscar Waddell 的[博士论文](https://web.archive.org/web/20010615153947/http://www.cs.indiana.edu/~owaddell/papers/thesis.ps.gz)（*警告*：.ps.gz 文件）。 > 第 3.5 节中描述的实现同时支持内部模块和顶层模块。对于内部模块，展开器生成的新名称必须在局部唯一，也就是说，在同一顶层表达式内不可见其他同名名称。对于单个编译单元内的顶层模块，名称必须在编译单元内唯一。当多个编译单元可能被链接在一起时，名称必须在各编译单元之间唯一。 > – Oscar Waddell，*Extending the Scope of Syntactic Abstraction*，§3.6.1 Chez Scheme 会为每次会话生成一个 UUID，该 UUID 被嵌入到 gensym 中，随后又被嵌入到代码中。这满足了分离编译之间需要不同唯一标识符的要求。它确保你自行使用编译器时一切顺畅。但我们想要的是可重现构建，也就是逐字节完全相同的构建，因此 UUID 就成了问题。在为 Linux 发行版构建包时，情况与你亲自使用编译器时略有不同。我们的构建系统能够知道构建中涉及了哪些代码，包括引入 Scheme 代码的依赖项；如果这些保持不变，那么与上次构建相同代码相比，就无需使用不同的标识符。我正在琢磨一种方案：从包版本号生成会话密钥，并将其传递给 `configure`。我认为这可以在不改动构建系统（Zuo 代码）之外任何东西的情况下完成。从概念上讲，我们会这样做： `(#%$set-top-level-value! '$session-key "k-") (compile-file "s/foo.ss")` 至于这是否足够，或者是否还有其他不确定性的来源，还有待观察。