所有你的代码库……都属于我们，但我们很高兴把它们还给你！这个组织是什么？我们为Zig构建系统打包C/C++项目，以便你可以轻松可靠地编译（和交叉编译！）它们。这为Zig编译器工具链的用户提供了便利，同时也向C/C++项目的维护者展示了他们项目的build.zig文件的样子。我维护了你们打包的一个项目，你们的工作提供了什么价值？一般来说，我们为你的项目增加了对Zig的依赖，但作为交换，我们删除了对以下工具的依赖：Make / GNUMake / CMake / autoconf / bash脚本 / batch脚本 / powershell脚本：Zig是一个完整的构建系统，在所有支持的平台上都能工作，并且可以完成其他工具所做的一切。Clang：Zig是一个完整的编译器工具链，恰好还打包了所有的clang。系统包管理器：Zig也是一个包管理器，可以下载和构建为其打包的依赖项，如果你希望的话。Docker / CI矩阵作业：Zig可以交叉编译C/C++/Zig代码，发布版本就像运行zig build release那么简单。更一般而言，Zig消除了对系统设置的所有依赖，同时仍然让你在需要时选择加入。我维护了你们打包的一个项目，并且我喜欢你们的工作，我该如何上游它？如果你是我们打包的项目的维护者，并决定升级你的构建管道，那么你可以自由地从我们的仓库上游你所需的一切。如果你决定这样做，请通过打开一个问题告诉我们，以便我们可以归档我们的仓库，并指引人们到你的上游项目。也可以在我们的仓库的Issues部分自由提问，询问如何正确地将一切集成到你的项目中（也许是因为我们没有实现第二个构建步骤）。最后一点需要注意：为了让我们能够归档我们的仓库，你的build.zig集成不得增加比我们的版本更多的系统依赖。因此，例如，如果我们打包的版本能够依赖于zstd通过allyourcodebase/zstd，那么我们恳请你要么继续依赖它（直到它的build.zig被上游），要么利用系统库集成功能给用户选择。话虽如此，你显然可以随意上游任何构建代码，即使你不打算通过Zig构建系统继续依赖其他包。我们当然会乐于在这种情况下帮助你，但我们也会继续维护我们的下游分支。你们打包的C/C++项目看起来是什么样子？我们使用两种主要策略：将上游项目作为依赖添加（在build.zig.zon中），并在我们的仓库中定义相应的build.zig脚本。分叉上游项目（可选地删除其他--现在没用的^_^--构建脚本），添加Zig构建脚本，并对原始项目应用任何必要的补丁。这最后一点通常不是必要的，但某些构建步骤可能通过使一些配置脚本更易于被Zig构建系统使用而受益。一个例子是让脚本接受输出路径作为参数，而不是硬编码它们的输出位置（这对于与Zig构建缓存正确集成非常有用）。如果你是上游项目的维护者，（1）清楚地表明你只需要两个文件（build.zig，build.zig.zon），但你需要清理所有其他构建脚本，并可能改进我们的Zig构建脚本，如上所述，而（2）则要求在上游工作时更加小心，但所有工作都将更彻底地为你完成（尽管你仍然可以选择直接获取Zig构建脚本文件，并手动审核如何将它们集成到你的上游项目中）。我是Zig用户，我想贡献一个仓库，我该如何做？联系kristoff并请求添加到组织中。以下是能够贡献仓库的一些基本规则：你的仓库必须对你的代码（新的build.zig文件）有许可，并且它必须至少与原项目的许可证一样宽松（为了简单起见，你可以使用MIT，并且永远不会出错）。你的仓库必须打包原始C/C++项目，而不添加额外的Zig特定内容，例如绑定。你可以将绑定放在由你直接拥有的单独仓库中。你必须针对最新标记的Zig版本。当移植原始项目时，你应该使用第一种策略（build.zig + 原始tarball），只有在：你需要补丁原始源代码以使其正确构建，或你将清理所有其他构建脚本并改进构建过程的中间步骤。如果你对第三点的一个例子是，改变项目特定的构建工具（例如资产处理工具，如图像优化器），它们硬编码输出路径（通常是cw