mozbuild.vendor 包

子模块

mozbuild.vendor.host_angle 模块

class mozbuild.vendor.host_angle.AngleHost(manifest)

基类: BaseHost

upstream_commit(revision)

upstream_snapshot(revision)

upstream_tag(revision)

临时克隆仓库以获取最新的标签和时间戳

mozbuild.vendor.host_base 模块

class mozbuild.vendor.host_base.BaseHost(manifest)

基类: object

download_single_file(url, destination)

upstream_path_to_file(revision, filepath)

upstream_release_artifact(revision, release_artifact)

upstream_snapshot(revision)

upstream_tag(revision)

临时克隆仓库以获取最新的标签和时间戳

mozbuild.vendor.host_codeberg 模块

class mozbuild.vendor.host_codeberg.CodebergHost(manifest)

基类: BaseHost

upstream_commit(revision)

查询 codeberg api 获取 git commit id 和时间戳。

upstream_snapshot(revision)

mozbuild.vendor.host_git 模块

class mozbuild.vendor.host_git.GitHost(*args, **kwargs)

基类: BaseHost

upstream_commit(revision)

upstream_snapshot(revision)

mozbuild.vendor.host_github 模块

class mozbuild.vendor.host_github.GitHubHost(manifest)

基类: BaseHost

api_get(path)

通用 Github API 获取。

upstream_commit(revision)

查询 github api 获取 git commit id 和时间戳。

upstream_path_to_file(revision, filepath)

upstream_release_artifact(revision, release_artifact)

upstream_snapshot(revision)

mozbuild.vendor.host_gitlab 模块

class mozbuild.vendor.host_gitlab.GitLabHost(manifest)

基类: BaseHost

upstream_commit(revision)

查询 gitlab api 获取 git commit id 和时间戳。

upstream_snapshot(revision)

mozbuild.vendor.host_googlesource 模块

class mozbuild.vendor.host_googlesource.GoogleSourceHost(manifest)

基类: BaseHost

upstream_commit(revision)

查询 git commit 和时间戳。

upstream_path_to_file(revision, filepath)

upstream_snapshot(revision)

mozbuild.vendor.mach_commands 模块

mozbuild.vendor.mach_commands.check_modified_files(command_context)

确保工作副本中没有未提交的文件更改，因为我们将要更改用户的一些状态。

mozbuild.vendor.mach_commands.vendor(command_context, library, revision, ignore_modified=False, check_for_update=False, add_to_exports=False, force=False, verify=False, patch_mode=None)

将第三方依赖项引入源代码存储库。

可以使用 ./mach vendor [rust/python] 引入 rust 和 python。可以使用 ./mach vendor [arguments] path/to/file.yaml 引入其他库。

mozbuild.vendor.mach_commands.vendor_python(command_context, keep_extra_files, add, remove, upgrade, upgrade_package, force)

mozbuild.vendor.mach_commands.vendor_rust(command_context, **kwargs)

mozbuild.vendor.moz_yaml 模块

class mozbuild.vendor.moz_yaml.License

基类: object

Voluptuous 验证器，用于验证许可证是否符合我们的允许列表。

exception mozbuild.vendor.moz_yaml.MozYamlVerifyError(filename, error)

基类：Exception

mozbuild.vendor.moz_yaml.RE_FIELD(string, pos=0, endpos=9223372036854775807)

扫描字符串以查找匹配项，并返回相应的匹配对象实例。

如果字符串中没有匹配的位置，则返回 None。

mozbuild.vendor.moz_yaml.RE_SECTION(string, pos=0, endpos=9223372036854775807)

扫描字符串以查找匹配项，并返回相应的匹配对象实例。

如果字符串中没有匹配的位置，则返回 None。

class mozbuild.vendor.moz_yaml.UpdateActions

基类: object

Voluptuous 验证器，用于验证更新操作是否有效。

class mozbuild.vendor.moz_yaml.UpdatebotTasks

基类: object

Voluptuous 验证器，用于验证更新机器人任务是否有效。

mozbuild.vendor.moz_yaml.VALID_SOURCE_HOSTS = ['gitlab', 'googlesource', 'github', 'angle', 'codeberg', 'git', 'yaml-dir']

— # 第三方库模板 # 所有字段都是强制性的，除非另有说明

# 此模式的版本 schema: 1

bugzilla

# 此目录和子目录的 Bugzilla 产品和组件 product: 产品名称 component: 组件名称

# 文档外部托管代码的来源 origin

# 包/库的简称 name: 包的名称

description: 简短（一行）描述

# 包的主页/等的完整 URL # 通常与存储库 URL 不同 url: 包的主页 URL

# 此版本/发布的人类可读标识符 # 通常是“版本 NNN”、“标签 SSS”、“书签 SSS” release: 标识符

# 要提取的修订版 # 必须是长或短的提交 SHA（建议使用长 SHA） revision: sha

# 包的许可证，如果可能，请使用来自 # https://spdx.org/licenses/ 的助记符 # 可以指定多个许可证（作为 YAML 列表） # 必须存在一个“LICENSE”文件，其中包含完整的许可证文本 license: MPL-2.0

# 如果包的许可证在特定文件中指定， # 则这是该文件的名称。 # 可选 license-file: COPYING

# 如果您想对库添加任何特定于 Mozilla 的注释， # 则可以将其放在此处。 notes: 关于库的注释

# 自动供应商系统的配置。 # 可选 vendoring

# 要从中提取供应商的存储库 URL # 例如 https://github.com/kinetiknz/nestegg # 可以在此处指定任何存储库主机，但是最初我们只 # 支持从选定的源进行自动提取。 url: 源 URL（通常是存储库克隆 URL）

# 上游存储库的主机类型 # 有效值为“gitlab”、“github”、“googlesource” source-hosting: gitlab

# 提取类型 # 这可以是“regular”、“individual-files”或“rust” # 如果省略，将默认为“regular” flavor: rust

# 要跟踪更新的 git 引用类型（提交、标签）。 # 您不能将标签跟踪与 individual-files 风格一起使用 # 如果省略，将默认为跟踪提交。 tracking: commit

# 使用标签跟踪（目前仅在 Github 上）时，请使用发布工件 # 作为源代码，而不是自动构建的 git-archive 导出文件。 # 源存储库必须为每个标签使用一致的文件名构建这些工件 # 这在 Github 存储库使用子模块时很有用 # 因为它们不包含在 git-archive 中。 # 对文件名执行替换，“{tag}”将替换为标签名称。 # 可选 release-artifact: “rnp-{tag}.tar.gz”

# 源文件将在树中所在的目录的基目录。 # 如果省略，将默认为 moz.yaml 文件所在的目录。 vendor-directory: third_party/directory

# 允许跳过提取过程的某些步骤。 # 如果例如上游提取很复杂并且应该由脚本完成，则最有用 # 可以跳过的有效步骤列在下面 skip-vendoring-steps

• fetch

• keep

• include

• exclude

• move-contents

• hg-add

• spurious-check

• update-moz-yaml

• update-moz-build

# 要在提取后应用的补丁文件列表。按指定的顺序应用 # 如果使用通配符，则按字母顺序排列。补丁必须 # 在更改被推送之前应用干净。 # 补丁文件应相对于 vendor-directory 而不是 gecko # 根目录。 # 所有补丁文件都隐式添加到 keep 文件列表中。 # 可选 patches

• file

• path/to/file

• path/*.patch

• path/** # 捕获 path 下的所有文件和子目录

• path/* # 捕获所有文件，但不捕获 path 下的子目录。等效于 path/

# 在提取库的新版本时，不会从目标目录中删除的文件列表 # 在库的新版本中。用于不在上游的 Mozilla 文件。 # 隐式包含“moz.yaml”、“moz.build”和 # “patches”中引用的任何文件 # 可选 keep

• file

• path/to/file

• another/path

• *.mozilla

# 不会从上游存储库提取的文件/路径 # 隐式包含“.git”和“.gitignore” # 可选 exclude

• file

• path/to/file

• another/path

• docs

• src/*.test

# 即使 # 它们会被“exclude”排除在外，也会始终从源存储库提取的文件/路径。 # 可选 include

• file

• path/to/file

• another/path

• docs/LICENSE.*

# 更新过程中修改的文件。 # 为避免创建未更新任何内容的更新，./mach vendor 将检测 # 是否有任何树内文件已更改。如果有一些文件始终更改 # 在更新过程中（例如版本号或源修订版），请将它们 # 列出在这里，以避免将它们计算为实质性更改。 # 此字段不支持目录或通配符 # 可选 generated

• ‘{yaml_dir}/vcs_version.h’

# 如果既未设置“exclude”也未设置“include”，则将提取所有文件 # 即使被排除在外，“include”中的文件/路径也将始终被提取 # 例如，排除“docs/”然后包含“docs/LICENSE”将仅提取 # docs 目录中的 LICENSE 文件

# 所有三个文件/路径参数（“keep”、“exclude”和“include”）都支持 # 文件名、目录名和通配符。

# 更新后要执行的操作。按顺序应用。 # action 子字段是必需的。它必须是以下之一： # - copy-file # - move-file # - move-dir # - replace-in-file # - replace-in-file-regex # - delete-path # - run-script # 除非另有说明，否则操作的所有子字段都是必需的。 # # 如果操作是 copy-file、move-file 或 move-dir： # from 是源文件 # to 是目标 # # 如果操作是 replace-in-file 或 replace-in-file-regex： # pattern 是文件中要搜索的内容。它是精确的字符串匹配。 # with 是要替换它的字符串。接受特殊关键字 # ‘{revision}’ 表示我们要更新到的提交。 # File 是要替换它的文件。 # # 如果操作是 delete-path # path 是要递归删除的文件或目录 # # 如果操作是 run-script： # script 是要运行的脚本 # cwd 是脚本应将其用作 cwd 的目录 # args 是要传递给脚本的参数列表 # # 如果操作是 run-command： # command 是要运行的命令 # 与 run-script 不同，command _不会_被处理为相对于 # 供应商目录，并且会直接传递给 python 的 # 执行代码，没有任何路径替换或操作 # cwd 是命令应将其用作 cwd 的目录 # args 是要传递给命令的参数列表 # # # 除非另有说明，否则所有文件/目录都相对于 # vendor-directory。如果 vendor-directory 与 # yaml 文件的目录不同，则可以使用关键字“{yaml_dir}” # 使路径相对于该目录。 # ‘run-script’ 支持附加关键字 {cwd}，如果使用， # 则只能在路径的开头使用。 # # 可选 update-actions

• action: copy-file from: include/vcs_version.h.in to: ‘{yaml_dir}/vcs_version.h’

• action: replace-in-file pattern: ‘@VCS_TAG@’ with: ‘{revision}’ file: ‘{yaml_dir}/vcs_version.h’

• action: delete-path path: ‘{yaml_dir}/config’

• action: run-script script: ‘{cwd}/generate_sources.sh’ cwd: ‘{yaml_dir}’

# 自动更新系统的配置。 # 可选 updatebot

# TODO：允许指定多个用户 # 库维护者的 Phabricator 用户名，用于分配 # 评审员。对于评审组，请以 # 为前缀，例如“#build”” maintainer-phab: tjr

# 库维护者的 Bugzilla 电子邮件地址，用于 needinfo maintainer-bz: tom@mozilla.com

# 可选：要使用的 ./mach try 预设。如果存在，则 fuzzy-query 和 fuzzy-paths # 将被忽略。如果它、fuzzy-query 和 fuzzy-path 被省略，则将使用 ./mach try auto try-preset: media

# 可选：./mach try fuzzy 的查询字符串。如果 try-preset、它和 fuzzy-paths 被省略 # 则将使用 ./mach try auto fuzzy-query: media

# 可选：./mach try fuzzy 的测试路径数组。如果 try-preset、它和 fuzzy-query 被省略 # 则将使用 ./mach try auto fuzzy-paths: [‘media’]

# 更新机器人可以运行的任务。目前仅允许每个任务一个 # 可选 tasks

• type: commit-alert branch: upstream-branch-name cc: [”bugzilla@email.address”, “another@example.com”] needinfo: [”bugzilla@email.address”, “another@example.com”] enabled: True filter: security frequency: every platform: windows blocking: 1234

• type: vendoring branch: master enabled: False

  # frequency 可以是“every”、“release”、“N 周”、“N 次提交” # 或“N 周，M 次提交”，需要满足两个约束条件。 frequency: 2 weeks

mozbuild.vendor.moz_yaml.load_moz_yaml(filename, verify=True, require_license_file=True)

加载并验证指定的清单。

mozbuild.vendor.rewrite_mozbuild 模块

问题

./mach vendor 需要能够自动向 moz.build 文件添加或删除文件，以便能够有效地自动更新库并在其中发送有用的 try 运行。

到目前为止，这样做一直很困难。

原因

• 某些文件需要进入 UNIFIED_SOURCES 而不是 SOURCES

• 某些文件是特定于操作系统的，需要进入每个操作系统的条件语句

• 某些文件同时对 UNIFIED_SOURCES/SOURCES 敏感且特定于操作系统。

建议

设计一种算法，将第三方库文件映射到可疑的 moz.build 位置。对所有第三方库的 moz.build 文件中指定的所有文件运行该算法。查看 moz.build 文件中建议的位置是否与实际位置匹配。

初始算法

给定一个文件，其中包含文件名和从 Gecko 根目录开始的路径，我们希望找到正确的 moz.build 文件以及该文件中该文件的位置。获取文件路径，并向上遍历目录树，查找 moz.build 文件。考虑每个 moz.build 文件，从最靠近文件的文件开始。在一个 moz.build 文件中，识别包含与要添加的文件位于同一目录路径的文件的 SOURCES 或 UNIFIED_SOURCES 块。如果只有一个这样的块，则使用该块。如果有多个块，则查看每个块中的文件，并记下公共前缀的最长长度（包括部分文件名 - 如果我们只执行完整目录，则结果将与上一步相同，并且我们不会缩小结果范围）。使用包含最长前缀的块。（我们称之为“猜测”。）

提案的结果

初始实现适用于 1977 个合格文件中的 1675 个。它不适用的文件包括

• 一般性故障。例如，当我们发现 avutil.cpp 想要与 adler32.cpp 相邻，但 avutil.cpp 在 SOURCES 中而 adler32.cpp 在 UNIFIED_SOURCES 中时。（以及许多类似的情况。）

• 每个 CPU 特征文件，其中只有一个文件在条件下添加

• 在猜测时，由于 len(…) > longest_so_far 的比较，我们会优先选择我们找到的第一个块。- 将此更改为在出现平局时优先选择 UNIFIED_SOURCES

  产生了 17 个额外的正确分配（大约提高了 1%）

• 由于上面更改的结果，在猜测时，因为在给定相等的前缀时，我们会优先选择 UNIFIED_SOURCES 块而不是其他块，即使其他块更长 - 将此（再次）更改为优先选择包含更多文件的块，产生了 49 个额外的

  正确分配（大约提高了 2.5%）

不适合考虑的文件是

• libwebrtc 中的文件

• 在由生成器组成的源分配中指定的文件（例如 [f for f in ‘%.c’]）

• 在对带下标变量的源分配中指定的文件（例如 SOURCES += foo[‘x86_files’]）

我们需要向上遍历目录并查看不同的 moz.build 文件 _零_ 次。

这表明此代码可能不需要，因此我们将从算法中删除它。

我们需要根据最长前缀猜测 944 次，这表明此代码是

绝对至关重要，应仔细检查。（实际上，在仔细检查后，发现了错误。）

经过一些初步测试，确定当供应商目录与 moz.yaml 目录不同时，此代码完全失效（以下定义）。代码进行了轻微重构以处理这种情况，主要通过 (a) 重新插入检查多个 moz.build 文件而不是第一个文件的逻辑，以及 (b) 处理一些复杂的规范化概念（详细信息在注释中）。

稍微改进的算法更改

不要费心向上遍历目录树查找 moz.build 文件，只需获取第一个文件。在猜测时，如果出现公共前缀平局，则优先选择包含更多文件的块

通过这些更改，我们现在成功匹配了 1977 个文件中的 1724 个

代码概念

源分配

将文件分配给 SOURCES 或 UNIFIED_SOURCES 变量，例如 SOURCES += [‘ffpvx.cpp’]

我们专门查找这两个变量名，以避免识别诸如 CXX_FLAGS 之类的东西。

但是，有时会存在中间变量，例如 SOURCES += celt_filenames 在这种情况下，我们会找到 celt_filenames 分配，并将其视为“源分配”

源分配位置

源分配位置是可读的字符串，用于识别 moz.build 文件中源分配的位置。它可用于在手动检查时直观地匹配位置；并且给定源分配位置，在迭代文件中的所有源分配时重新识别它。

实际字符串由从 moz.build 文件的根目录到源分配的路径加上后缀数字组成。

我们在最终值后面添加一个递增计数器作为后缀。这是为了支持 moz.build 文件，出于某种原因，在同一个基本块中使用多个 SOURCES += [] 列表。此索引是每个文件的，因此同一文件中的任何两个分配（即使它们具有不同的位置）都不应具有相同的后缀。

例如

当 SOURCES += [‘ffpvx.xpp’] 作为文件的首行出现（或任何其他未缩进的位置）时，其源分配位置将为 > SOURCES 1。

当 SOURCES += [‘ffpvx.xpp’] 出现在条件语句中，例如 CONFIG[‘OS_TARGET’] == ‘WINNT’ 时，其源分配位置将为 > if CONFIG[‘OS_TARGET’] == ‘WINNT’ > SOURCES 1

当 SOURCES += [‘ffpvx.xpp’] 作为文件的第二行出现，并且不同的 SOURCES += [] 是第一行时，则其源分配位置将为“> SOURCES 2”。

任何两个源分配都不可能有相同的源分配位置。如果它们相同，我们会引发断言。

文件与文件名

“文件名”是指定文件名称和有时文件路径的字符串。“文件”是从打开文件名获得的对象

作为字符串的变量应始终使用“文件名”

供应商目录与 moz.yaml 目录

在许多情况下，库的 moz.yaml 文件、moz.build 文件和源文件都位于同一个目录下。例如 libjpeg

在其他情况下，库的源文件位于一个目录中（我们称之为“供应商目录”），而 moz.yaml 文件和 moz.build 文件位于另一个目录中（我们称之为 moz.yaml 目录）。例如 libdav1d

规范化文件名

如果文件名已扩展到从 Gecko 根目录开始的完整路径，则该文件名已“规范化”。这需要一个 moz.build 文件。

例如，文件名 lib/opus.c 可能在 media/libopus/moz.build 文件中指定。通过将 moz.build 文件的 dirname（即 media/libopus）连接到文件名来规范化文件名，从而得到 media/libopus/lib/opus.c

以“/”开头的文件名被认为已相对于 Gecko 根目录指定，因此不会修改。

在处理单独的供应商和 moz.yaml 目录时，规范化变得更加复杂。这是因为当文件看起来像 third_party/libdav1d/src/a.cpp _或_ 当它看起来像 media/libdav1d/../../third_party/libdav1d/src/a.cpp 时，它可以被认为是规范化的。这是因为在 moz.build 文件中，它将被指定为 ../../third_party/libdav1d/src/a.cpp，我们通过在其前面添加 moz.build 文件的路径来对其进行“规范化”。

规范化不仅仅是拥有从 gecko_root 到文件的“绝对”路径。实际上，它根本与之无关 - 它与匹配文件名有关。因此，当我们处理单独的供应商和 moz.yaml 目录时，我们会非常快速地“重新规范化”规范化的文件名，以使其进入其中一个 foo/bar/../../third_party/… 路径，这对于我们感兴趣的 moz.build 文件才有意义。

每当规范化文件名时，都应在变量名中指定，作为前缀（normalized_filename）或后缀（target_filename_normalized）

统计数据

使用一些技巧，我们报告有关我们访问代码某些分支多少次的统计数据。例如

• “我们根据前缀长度细化猜测多少次”

• “我们根据块中的文件数量细化猜测多少次”

• “猜测候选者的直方图是什么”

我们这样做是为了识别某些代码路径被执行的频率，从而识别异常行为并调查异常值。此过程导致识别错误和进行小幅改进。

exception mozbuild.vendor.rewrite_mozbuild.MozBuildRewriteException

基类：Exception

mozbuild.vendor.rewrite_mozbuild.add_file_to_moz_build_file(normalized_filename_to_add, moz_yaml_dir=None, vendoring_dir=None)

这是总体功能。给定一个相对于 Gecko 根目录的文件名（也称为规范化文件名），我们会查找要将其添加到其中的 moz.build 文件，查找要在 moz.build 文件中添加该文件的位置，然后就地编辑该 moz.build 文件。

它接受两个可选参数。如果指定了一个参数，则必须同时指定这两个参数。如果库在与 moz.yaml 文件不同的位置进行版本控制，则这些参数指定这两个目录。

mozbuild.vendor.rewrite_mozbuild.assignment_node_to_source_filename_list(code, node)

如果文件名列表不是常量列表（例如，它是生成的列表），则（可能）无法尝试找出它。至少我们现在不会尝试。也许将来会？

如果发生这种情况，我们将返回一个空列表。这样做的后果是我们无法将文件与该列表匹配，因此我们可能无法添加它。

（但是如果文件与生成的列表匹配，它可能会自动包含在 Sources 列表中？）

mozbuild.vendor.rewrite_mozbuild.ast_get_source_segment(code, node)

mozbuild.vendor.rewrite_mozbuild.edit_moz_build_file_to_add_file(normalized_mozbuild_filename, unnormalized_filename_to_add, unnormalized_list_of_files)

此函数就地编辑 moz.build 文件

我真的很希望用一些将节点添加到 AST、转储 AST，然后对文件运行 black 的东西来替换整个该功能，但存在一些问题：- 第三方 moz.build 文件（或者可能是所有 moz.build 文件）并不总是通过 black 运行 - 转储 AST 会丢失注释

mozbuild.vendor.rewrite_mozbuild.edit_moz_build_file_to_remove_file(normalized_mozbuild_filename, unnormalized_filename_to_remove)

此函数就地编辑 moz.build 文件

mozbuild.vendor.rewrite_mozbuild.filenames_directory_is_in_filename_list(filename_normalized, list_of_normalized_filenames)

给定一个规范化的文件名和一个规范化的文件名列表，首先将它们转换为包含目录和包含目录列表。然后测试文件名的包含目录是否在列表中。

例如

f = filenames_directory_is_in_filename_list f(“foo/bar/a.c”, [“foo/b.c”]) -> false f(“foo/bar/a.c”, [“foo/b.c”, “foo/bar/c.c”]) -> true f(“foo/bar/a.c”, [“foo/b.c”, “foo/bar/baz/d.c”]) -> false

mozbuild.vendor.rewrite_mozbuild.find_all_posible_assignments_from_filename(source_assignments, filename_normalized)

给定一个源分配列表和一个规范化的文件名，将列表缩小到包含文件目录与文件名目录匹配的文件的分配。

mozbuild.vendor.rewrite_mozbuild.get_all_mozbuild_filenames(gecko_root)

查找 Gecko 存储库中所有第三方 moz.build 文件

mozbuild.vendor.rewrite_mozbuild.get_all_target_filenames_normalized(all_mozbuild_filenames_normalized)

给定一个 moz.build 文件列表，返回所有文件中所有源代码分配中列出的文件。

此函数仅用于调试/测试目的 - 没有理由将其作为“算法”的一部分调用。

mozbuild.vendor.rewrite_mozbuild.get_attribute_label(node)

mozbuild.vendor.rewrite_mozbuild.get_closest_mozbuild_file(normalized_filename, moz_yaml_dir=None, vendoring_dir=None, all_mozbuild_filenames_normalized=None)

返回目录树中与规范化文件名最接近的 moz.build 文件。

mozbuild.vendor.rewrite_mozbuild.get_file_reference_modes(source_assignments)

给定一组源代码分配，此函数遍历这些分配中引用的文件，以查看文件是使用绝对路径（相对于 gecko 根目录）还是相对路径引用。

它将返回所有看到的模式。

mozbuild.vendor.rewrite_mozbuild.get_gecko_root()

使用 __file__ 作为基础，查找 gecko 根目录。

mozbuild.vendor.rewrite_mozbuild.get_mozbuild_file_search_order(normalized_filename, moz_yaml_dir=None, vendoring_dir=None, all_mozbuild_filenames_normalized=None)

返回一个有序列表，其中包含要考虑的给定文件名的规范化 moz.build 文件名。

normalized_filename：规范化为 gecko 根目录的源文件名。

moz_yaml_dir：从 gecko_root 到 moz.yaml 文件（它是 moz.build 文件的根目录）的路径。

moz_yaml_dir：库源文件所在的路径。

all_mozbuild_filenames_normalized：（可选）所有第三方 moz.build 文件的列表。如果未指定 all_mozbuild_filenames_normalized，我们将查找文件系统。

该列表由两个不同的步骤构建。

在步骤 1 中，我们将向上遍历目录树，查找 moz.build 文件。我们按此顺序追加 moz.build 文件，优先考虑我们找到的最低 moz.build 文件，然后继续到更高目录中的文件。我们开始所在的目录有点复杂。我们获取 vendoring_dir 和相关文件之间的一系列子目录，然后将它们附加到 moz.yaml 目录。

示例

When moz_yaml directory != vendoring_directory:
    moz_yaml_dir = foo/bar/
    vendoring_dir = third_party/baz/
    normalized_filename = third_party/baz/asm/arm/a.S
    starting_directory: foo/bar/asm/arm/
When moz_yaml directory == vendoring_directory
    (In this case, these variables will actually be 'None' but the algorthm is the same)
    moz_yaml_dir = foo/bar/
    vendoring_dir = foo/bar/
    normalized_filename = foo/bar/asm/arm/a.S
    starting_directory: foo/bar/asm/arm/

在步骤 2 中，我们变得有点绝望。当 vendoring 目录和 moz_yaml 目录不同时，无法保证 moz_yaml 目录会遵循与 vendoring 目录相同的目录结构。实际上，在某些情况下（例如 libdav1d）并非如此。因此，在这种情况下，我们从 moz_yaml 目录的根目录开始向下遍历，将遇到的_任何_ moz.build 文件添加到列表中。稍后（在所有情况下，不仅是 moz_yaml_dir != vendoring_dir），我们仅在 moz.build 文件的源文件目录与 normalized_filename 匹配时才考虑该文件，因此，尽管此步骤很绝望，但它是安全的，并且令人难以置信的是，它对一些文件添加有效。

mozbuild.vendor.rewrite_mozbuild.guess_best_assignment(source_assignments, filename_normalized)

给定多个分配，所有分配都包含与文件名相同的目录，选择我们认为最佳的一个并返回其 source-assignment-location。

我们通过查看文件名本身（不仅仅是其目录）并选择包含具有最长匹配前缀的文件名的分配来实现此目的。

例如：“foo/asm_neon.c”与 [“foo/main.c”, “foo/all_utility.c”], [“foo/asm_arm.c”] 进行比较。

-> [“foo/asm_arm.c”]（匹配 foo/asm_）。

mozbuild.vendor.rewrite_mozbuild.log(*args, **kwargs)

mozbuild.vendor.rewrite_mozbuild.mozbuild_file_to_source_assignments(normalized_mozbuild_filename, assignment_type)

返回一个字典，其中包含指定 moz.build 文件中包含的“source-assignment-location” ->“规范化源文件名列表”。

normalized_mozbuild_filename：要读取的 moz.build 文件。

mozbuild.vendor.rewrite_mozbuild.node_to_name(code, node)

mozbuild.vendor.rewrite_mozbuild.node_to_readable_file_location(code, node, child_node=None)

mozbuild.vendor.rewrite_mozbuild.normalize_filename(normalized_mozbuild_filename, filename)

mozbuild.vendor.rewrite_mozbuild.remove_file_from_moz_build_file(normalized_filename_to_remove, moz_yaml_dir=None, vendoring_dir=None)

给定一个文件名，相对于 gecko 根目录（也称为规范化），我们查找最近的 moz.build 文件，在该文件中查找文件，然后就地编辑该 moz.build 文件。

mozbuild.vendor.rewrite_mozbuild.renormalize_filename(mode, moz_yaml_dir, vendoring_dir, normalized_mozbuild_filename, normalized_filename_to_act_on)

将 normalized_filename_to_act_on 编辑为

• 使其成为从 gecko 根目录开始的绝对路径（如果我们处于该模式）。

• 获取从 vendoring 目录到 moz.build 文件所在的 yaml 目录的相对路径（如果它们在单独的目录中）。

mozbuild.vendor.rewrite_mozbuild.test_all_third_party_files(gecko_root, all_mozbuild_filenames_normalized)

对第三方 moz.build 文件中的每个源文件运行算法并输出结果。

mozbuild.vendor.rewrite_mozbuild.try_to_match_target_file(all_mozbuild_filenames_normalized, target_filename_normalized)

对目标文件运行“算法”，并返回算法是否成功。

all_mozbuild_filenames_normalized：所有第三方 moz.build 文件的列表 target_filename_normalized - 目标文件名，规范化为 gecko 根目录。

mozbuild.vendor.rewrite_mozbuild.unnormalize_filename(normalized_mozbuild_filename, normalized_filename)

mozbuild.vendor.rewrite_mozbuild.validate_directory_parameters(moz_yaml_dir, vendoring_dir)

mozbuild.vendor.vendor_manifest 模块

class mozbuild.vendor.vendor_manifest.VendorManifest(topsrcdir, settings, log_manager, topobjdir=None, mozconfig=<object object>, virtualenv_name=None)

基类：MozbuildObject

convert_patterns_to_paths(directory, patterns)

fetch_and_unpack(revision)

获取并解压缩上游源代码。

fetch_individual(new_revision)

get_full_path(path, support_cwd=False)

get_source_host()

import_local_patches(patches, yaml_dir, vendor_dir)

process_individual(new_revision, timestamp, ignore_modified, add_to_exports)

process_regular(new_revision, timestamp, ignore_modified, add_to_exports)

process_regular_or_individual(is_individual, new_revision, timestamp, ignore_modified, add_to_exports)

process_rust(command_context, old_revision, new_revision, timestamp, ignore_modified)

should_perform_step(step)

spurious_check(revision, ignore_modified)

update_files(revision)

update_moz_build(vendoring_dir, moz_yaml_dir, add_to_exports)

update_yaml(revision, timestamp)

vendor(command_context, yaml_file, manifest, revision, ignore_modified, check_for_update, force, add_to_exports, patch_mode)

mozbuild.vendor.vendor_manifest.iglob_hidden(*args, **kwargs)

mozbuild.vendor.vendor_manifest.list_of_paths_to_readable_string(paths)

mozbuild.vendor.vendor_manifest.throwe()

mozbuild.vendor.vendor_python 模块

class mozbuild.vendor.vendor_python.VendorPython(*args, **kwargs)

基类：MozbuildObject

vendor(keep_extra_files=False, add=None, remove=None, upgrade=False, upgrade_package=None, force=False)

mozbuild.vendor.vendor_python.hash_file_text(file_path)

mozbuild.vendor.vendor_python.remove_environment_markers_from_requirements_txt(requirements_txt: Path)

mozbuild.vendor.vendor_rust 模块

class mozbuild.vendor.vendor_rust.VendorRust(*args, **kwargs)

基类：MozbuildObject

BUILDTIME_LICENSE_WHITELIST = {'BSD-3-Clause': ['bindgen', 'fuchsia-zircon', 'fuchsia-zircon-sys', 'fuchsia-cprng', 'glsl', 'instant']}

ICU4X_LICENSE_SHA256 = '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978'

RUNTIME_LICENSE_FILE_PACKAGE_WHITELIST = {'deque': '6485b8ed310d3f0340bf1ad1f47645069ce4069dcc6bb46c7d5c6faf41de1fdb', 'fuchsia-cprng': '03b114f53e6587a398931762ee11e2395bfdba252a329940e2c8c9e81813845b', 'icu_calendar': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_calendar_data': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_collections': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_locid': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_locid_transform': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_locid_transform_data': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_properties': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_properties_data': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_provider': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_provider_adapters': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_provider_macros': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'icu_segmenter': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'litemap': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'tinystr': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'writeable': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'yoke': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'yoke-derive': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'zerofrom': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'zerofrom-derive': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'zerovec': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978', 'zerovec-derive': '853f87c96f3d249f200fec6db1114427bc8bdf4afddc93c576956d78152ce978'}

RUNTIME_LICENSE_PACKAGE_WHITELIST = {'BSD-2-Clause': ['arrayref', 'mach', 'qlog'], 'BSD-3-Clause': ['subtle']}

RUNTIME_LICENSE_WHITELIST = ['Apache-2.0', 'Apache-2.0 WITH LLVM-exception', 'CC0-1.0', 'ISC', 'MIT', 'MPL-2.0', 'Unicode-3.0', 'Unicode-DFS-2016', 'Unlicense', 'Zlib']

check_cargo_version(cargo)

确保 Cargo 版本足够新。

check_openssl()

设置使用 openssl 构建的环境标志。

MacOS 不包含 openssl，但 mach-vendor 使用的 openssl-sys crate 期望系统中存在一个。通常情况下，homebrew 会将 openssl 安装到 /usr/local/opt/openssl，但需要自定义链接标志才能针对它进行构建。

get_cargo_path()

has_modified_files()

确保工作副本中没有对文件进行未提交的更改，因为我们将更改用户的一些状态。允许更改 Cargo.{toml,lock}，因为这可能是常见的使用案例。

log(level, action, params, format_str)

记录结构化日志事件。

结构化日志事件由日志级别、字符串操作、属性字典和格式化字符串组成。

日志级别是 logging.* 常量之一，例如 logging.INFO。

操作字符串本质上是事件的枚举。每种不同类型的记录事件都应该有不同的操作。

params 字典是构成记录事件的元数据。

格式化字符串用于将结构化消息转换回人类可读的格式。通过对该字符串调用 format() 并将其馈入构成事件的属性字典来执行转换回人类可读形式。

示例用法

self.log(logging.DEBUG, 'login', {'username': 'johndoe'},
    'User login: {username}')

static runtime_license(package, license_string)

Cargo 文档说明：— https://doc.rust-lang.net.cn/cargo/reference/manifest.html

这是此软件包的 SPDX 2.1 许可证表达式。当前，crates.io 将根据 SPDX 许可证列表 2.4 中已知许可证和例外标识符的白名单验证提供的许可证。目前不支持括号。

可以使用 / 分隔多个许可证，尽管此用法已弃用。相反，请使用带有 AND 和 OR 运算符的许可证表达式以获得更明确的语义。— 但我不知道如何有意义地 AND 许可证，因此如果检测到这种情况，我们将中止。我们将处理 / 和 OR 作为等效项，并在我们的批准列表中批准任何一个。

serialize_issues_json()

vendor(ignore_modified=False, force=False)

模块内容