将新项目添加到 WrapDB

工作原理

新的包装必须作为工作子项目提交到 wrapdb 仓库.

WrapDB 上有两种类型的包装 - 常规包装和带有 Meson 构建定义补丁的包装。

带有 Meson 构建定义补丁的包装与 Debian 的工作方式大致相同：我们采用未修改的上游源代码包，并添加一个新的构建系统作为补丁。这些构建系统存储在 subprojects/packagefiles/ 的子目录中。它们只包含构建定义文件。您也可以将它们视为对上游源代码的覆盖。

没有 Meson 构建定义补丁的包装只包含描述如何获取项目的包装元数据。

每当将新的版本推送到 wrapdb 时，都会生成一个带有递增版本号的新标签，并将一个新版本添加到 wrapdb API 列表中。所有旧版本保持不变。新提交始终通过 GitHub 合并请求进行，并且必须由提交者以外的人员进行审查。

请注意，您的带有包装的 Git 仓库不能包含源代码版本的子目录。该目录将由服务自动添加。您也不能将原始压缩包中的任何源代码提交到包装仓库。

选择包装名称

包装的子项目的使用方式与外部依赖项非常相似。因此，它们应该与上游项目具有相同的名称。

注意：包装名称必须完全匹配此正则表达式：[a-z0-9._]+。

如果项目提供了 pkg-config 文件，则包装名称应与 pkg-config 名称相同。通常情况下，这是项目的名称，例如 libpng。但有时会有所不同。例如，libogg 项目的 pkg-config 名称选择为 ogg 而不是 libogg，这就是包装命名为 ogg 的原因。

如果没有 pkg-config 文件，应使用项目使用的/推广的名称，仅使用小写字母（Catch2 -> catch2）。

如果项目名称过于通用或模棱两可（例如 benchmark），请考虑使用 组织-项目 命名格式（例如 google-benchmark）。

如何贡献新的包装

如果项目已经使用 Meson 构建系统，则只需要提供一个包装文件 project.wrap。否则，还应提供 Meson 构建定义补丁 - 一组 meson.build 文件。

创建包装内容

新的发布分支需要 project.wrap 文件，因此如果需要，请创建一个。

${EDITOR} upstream.wrap

文件格式很简单，请查看任何现有的 wrapdb 子项目以了解内容。校验和是 SHA-256，可以使用大多数类 Unix 操作系统上的以下命令进行计算

sha256sum path/to/libfoo-1.0.0.tar.gz

在 macOS 上，命令如下

shasum -a 256 path/to/libfoo-1.0.0.tar.gz

接下来，您需要添加定义当前项目提供的依赖项的条目。这一点很重要，因为它使 Meson 的自动依赖项解析器工作。这是通过在 upstream.wrap 文件末尾添加 provide 条目来完成的。以 Ogg 库为例，它看起来像这样

[provide]
ogg = ogg_dep

左侧的 ogg 指的是依赖项名称，它应该与其 Pkg-Config 名称相同。右侧的 ogg_dep 指的是构建定义中提供依赖项的变量。通常情况下，它包含 declare_dependency 调用的结果。如果没有定义该名称的变量，Meson 将以硬错误退出。有关更多详细信息，请参阅主要 Wrap 手册.

现在，您可以创建构建文件（如果上游项目不包含任何文件），并对其进行处理，直到项目正确构建。请记住，所有文件都位于 subprojects/packagefiles/<project-name> 目录中。

${EDITOR} meson.build meson.options

为了将本地添加的构建文件应用于上游发布压缩包，wrap-file 部分必须包含 patch_directory 属性，该属性命名 subprojects/packagefiles/ 中的子目录，该目录中包含构建文件，因为这是 wrapdb 工作方式的核心。它将由 wrapdb meson.build 使用，并且当创建发布时，来自此目录的文件将被转换为存档，并且 patch_url 将被添加到包装文件中。

当您对结果感到满意时，将构建文件添加到 Git，按照 README.md 中的说明更新 releases.json，并将结果推送到 GitHub。

<verify that your project builds and runs>
git add releases.json subprojects/project.wrap subprojects/packagefiles/project/
git commit -a -m 'Add wrap files for libfoo-1.0.0'
git push -u origin libfoo

现在，您应该在 GitHub 上创建一个拉取请求。

如果包装审查要求您进行更改，请使用 --amend 参数对 commit 进行更改，以便您的分支只有一个提交。

${EDITOR} meson.build
git commit -u --amend
git push --force

对原始源代码的更改

包装的目的是为上游项目提供尽可能少的更改。大多数项目不应该包含除了几个 Meson 定义文件以外的任何内容。有时，可能需要添加一个模板头文件或类似的东西。这些应该保持在最小限度。

尤其需要注意的是，**不能**对功能进行任何修补。所有这些更改都必须提交到上游。如果您愿意，您也可以将自己的更改托管在自己的 Git 仓库中。Wrap 系统原生支持 Git 子项目。

通过自动验证

每个提交的包装都会经过自动的正确性审查，并且通过审查是合并的先决条件。因此，强烈建议您自己运行验证检查，以便您可以更快地修复任何问题。

您可以使用以下命令测试包装本身

meson subprojects purge --confirm
meson setup builddir/ -Dwraps=<project-name>

第一个命令是确保从最新的 packagefiles 正确获取包装。第二个命令配置 meson 并选择一组要启用的子项目。

GitHub 项目包含自动 CI，在推送到运行项目并检查元数据以查找明显的错误时会运行。您可以在提交 PR 之前从您的 fork 检查此内容。

搜索结果为

在 GitHub 上编辑