开发工具【免费下载链接】rustupThe Rust toolchain installer项目地址https://gitcode.com/gh_mirrors/ru/rustup点击查看免费下载本文对应 rustup 仓库 开发指南 中的 Recipes 章节recipes.md。当 Rust 官方将一个目标平台target提升为带 host tools 的 Tier 2后rustup 就需要为其提供官方构建产物。本文完整讲解从告知 rustup 新目标到在 CI 中稳定启用该目标的完整流程并结合仓库中的 CI 模板、脚本与测试源码说明每一步背后的实现机制。读完本文你将掌握如何在linux-builds-template.yaml中登记新目标、skip-*注释的精确语义、如何在 PR 中临时启用 CI 验证以及如何判断何时可以移除skip-stable让新目标进入稳定发布。背景什么是带 Host Tools 的 Tier 2 目标Rust 官方按支持程度将目标平台划分为若干 tier。rustup 的原则是所有带 host tools 的 target tuple 都应当被 rustup 识别并拥有官方 rustup 构建产物如rustup-init、各平台发行包。所谓带 host tools指该平台不仅能交叉编译 Rust 程序还具备运行编译器、执行测试等宿主能力。因此一旦某个新目标被提升为 tier 2 with host toolsrustup 就应通过下述两步流程显式支持它Informing rustup告知 rustup 新目标的存在把目标加入构建矩阵但先在所有 CI 场景中禁用其构建Stabilizing稳定该目标当该目标在 stable Rust 中可用后按目标热度逐步在特定 CI 场景中启用。第一步告知 rustup 新目标Linux 交叉编译场景为什么聚焦 Linux截至本文写作时GitHub Actions 的 runner 原生支持 Linux、Windows 和 macOS 三个宿主系统。Tier 2 的构建大多通过从 Linux 交叉编译完成只有 Windows 与 macOS 目标在对应宿主机上直接编译。因此文档与本节重点讲解 Linux 场景Windows / macOS 新增目标的处理方式见下文专门小节。在 CI 模板中登记目标需要修改的核心文件是 ci/actions-templates/linux-builds-template.yaml。在strategy.matrix.target列表中为你的新目标增加一行例如target: - x86_64-unknown-linux-gnu - armv7-unknown-linux-gnueabihf # ... 其他已有目标 ... - your-new-target-tuple # skip-pr skip-main skip-stable关键点在于登记新目标时必须在本行末尾追加 YAML 注释# skip-pr skip-main skip-stable以在所有场景中禁用该目标的构建。此时新增目标只是被 rustup 知晓并不会真正进入任何 CI 构建流程。关于 skip 关键字的一个细节原文档中写作skip-master而当前仓库 linux-builds-template.yaml 中实际使用的关键字是skip-main例如aarch64-unknown-linux-musl # skip-pr skip-main、aarch64-unknown-freebsd # skip-pr skip-main skip-stable。这是模板演进过程中的命名差异动手修改时请以仓库中现行关键字为准。三个场景关键字分别为skip-prPR 场景、skip-mainmain 分支场景、skip-stablestable 分支场景。skip 注释是如何生效的模板生成机制你可能好奇 YAML 注释怎么会影响 CI 行为奥秘在于 ci/actions-templates/gen-workflows.shrustup 的正式工作流文件.github/workflows/ci.yaml不是手写的而是由模板脚本生成的。该脚本的核心逻辑gen_job () { grep -v skip-$2 $INPATH/$1-template.yaml $OUTPATH }即生成某个场景如pr、main、stable的 job 时用grep -v过滤掉模板中所有包含对应skip-*注释的行。因此生成 PR 场景gen_job linux-builds pr时# skip-pr所在行会被剔除生成 main 场景时# skip-main所在行被剔除生成 stable 场景时# skip-stable所在行被剔除。一行# skip-pr skip-main skip-stable意味着该目标在所有三个场景中都被过滤从而在所有场景禁用构建。同理移除某个skip-*就等于在对应场景中重新启用该目标。脚本还展示了完整的生成顺序依次调用windows-buildspr/main/stable、linux-buildspr/main/stable、macos-builds按 x86_64/aarch64 拆分、freebsd-buildsmain/stable以及centos-fmt-clippy、all-features、test-docs三个单 job最后通过conclusion汇总所有带# job-name标记的 job 到needs列表见 conclusion-template.yaml。所以修改任何模板后都需要重新运行./ci/actions-templates/gen-workflows.sh来重新生成工作流——这一点由 centos-fmt-clippy-template.yaml 中的 Run CI workflow generation checks 步骤自动校验运行脚本后git diff --exit-code若生成结果与已提交的工作流不一致则 CI 失败。构建矩阵的组织方式以 linux-builds-template.yaml 为例Linux 构建矩阵按以下方式组织matrix.mode目前固定为release每个目标都做 release 构建matrix.target目标平台列表含 x86_64-unknown-linux-gnu、armv7-unknown-linux-gnueabihf、aarch64-linux-android、各 BSD/Solaris/illumos、powerpc 系列、s390x、riscv64gc、loongarch64 等matrix.include为特定目标补充配置例如能在托管 runner 上原生运行测试的目标补充mode: dev此时会运行完整测试套件aarch64-unknown-linux-gnu使用ubuntu-24.04-armARM runnerAndroid 系列注释说明使用本地 docker 镜像见步骤中*-linux-android*分支带#snap_arch注释的目标预留了 snap 打包架构信息。登记新目标时除了在target列表加一行并附加# skip-pr skip-main skip-stable还需判断该目标是否满足测试套件可在托管 runner 上原生运行的条件以决定是否需要同步在include中添加mode: dev条目dev 模式走 ci/run.bash 的完整构建测试路径release 模式则只cargo build产出二进制并exit 0跳过测试。从告知到可构建的完整链路在 Linux 场景中模板里对该目标的构建最终会落到以下步骤见 linux-builds-template.yaml 的steps克隆仓库actions/checkoutv7fetch-depth: 0以便获取标签安装 rustup 自身sh ./rustup-init.sh --default-toolchainnone --profileminimal -y并保证 stable 工具链最新rustup target install $TARGET安装目标按目标选择 docker 镜像Android 用android本地镜像其余用目标 tuple 同名镜像见 ci/docker 目录下各 Dockerfilebash ci/fetch-rust-docker.bash ${TARGET}从 rust-lang/rust 拉取基础镜像若存在ci/docker/$DOCKER/Dockerfile则本地构建注意模板中特意禁用了 BuildKit规避 rustup 已知的 Docker 回归问题在 docker 内运行bash ci/run.bash设置BUILD_PROFILE、TARGET、SKIP_TESTS、INSTALL_BINDGEN1等环境变量release 模式下上传产物rustup-initactions/upload-artifactv7保留 7 天在 main/stable 分支的 push 上进一步执行ci/prepare-deploy.bash并上传到 S3dev-static-rust-lang-org/rustup/与rustup-builds/两个桶。其中 ci/run.bash 是实际构建脚本它会根据TARGET决定启用哪些 feature如reqwest-native-tls、vendored-openssl、reqwest-rustls-tls并对 aws-lc-rs 不支持的 powerpc*/mips*/loongarch*/netbsd*/illumos*/solaris* 平台跳过 rustls且对arm-linux-androideabi设置CFLAGS-marcharmv7。若SKIP_TESTS非空则只构建二进制后退出否则执行先全部构建、再全部测试的流程build_test build/RUSTUP_CI1 build_test test以缓解 7GB 内存 runner 上反复构建导致的换页问题。实践提示新增目标时建议对照一个已完成该流程的示例 PR。文档推荐的参考是 rustup#4688在 rustup 代码库中查找需要提及新目标的几乎所有位置的样例。注意本仓库为只读镜像实践时请在你的 rustup fork 上按上述步骤修改并提交 PR。第二步稳定目标Stabilizing何时以及如何启用当你的新目标在stable Rust中可用后就可以按目标的热门程度在特定 CI 场景中启用它了。具体操作是移除 linux-builds-template.yaml 中该行注释里的某些skip-*关键字。大多数情况下只需移除skip-stable即让该目标进入 stable 场景target: - your-new-target-tuple # skip-pr skip-main为什么通常只启 stable 场景从 linux-builds-template.yaml 顶部三个 job 的if条件可以看出stable 场景build-linux-stable不仅覆盖 stable 分支的 push还包含schedule定时触发与workflow_dispatch手动触发是发布与日常验证的核心场景而 PR 与 main 场景更偏日常开发对尚不成熟的新目标可以继续跳过。PR 验证流程先临时启用再正式合并文档特别强调为稳定目标创建 PR 时需要证明该目标在 CI 中确实能通过具体做法在单独的 commit中移除skip-pr临时在该 PR 的 CI 中启用这个目标等待该 PR 的 CI 变绿把该次 CI 运行的链接贴到 PR 讨论中供维护者验证文档给出的示例是 rustup#4816 的评论验证通过后安全地丢弃这个临时 commit如git rebase/ 交互式 rebase 删除该提交恢复skip-pr状态让 PR 具备合并条件。这一临时启用—验证—回滚的节奏既能在合并前拿到真实构建证据又不会在正式历史中引入未稳定的目标。请注意不要将临时提交与真实修改混在一起提交否则回滚时会把登记/启用逻辑一并删掉。Windows 与 macOS 新目标的处理文档明确说明如果需要支持新的 Windows 或 macOS 目标请在一个专门的 rustup issue 中与团队讨论而不是照搬 Linux 流程。原因从模板结构可以推断Windows 目标在 windows-builds-template.yaml 中直接于 Windows runner含windows-11-arm上编译涉及 MSVC/GNU/gnullvm 三种 ABI、NASM构建 aws-lc-rs 需要、mingw 与 llvm-mingw 工具链安装等复杂步骤且配置了RUSTFLAGS: -Ctarget-featurecrt-static静态链接策略macOS 目标在 macos-builds-template.yaml 中按架构拆分 jobbuild-macos-aarch64与build-macos-x86_64并各自设置MACOSX_DEPLOYMENT_TARGETaarch64 为 11.0x86_64 为 10.12release 构建还会用otool -L校验动态链接不含/usr/local路径。这两类目标由于涉及宿主工具链、签名与发布流程的特殊性不适合单凭模板加一行完成因此与团队先行沟通是必要的。相关验证与配套设施除构建矩阵外rustup 对目标平台还有一套配套校验新增目标时可一并关注target tuple 识别测试tests/suite/known_target_tuples.rs 中的gen_known_target_tuples测试会根据platformscrate 的Platform::ALL重新生成src/dist/target_tuple/known.rs架构/OS/环境三元组列表若与现有生成文件不一致则原地更新并报错。这印证了所有目标 tuple 都应为 rustup 所识别的原则——你的新目标需要能被正确解析为 arch / os / env 三段式该文件注释详述了x-y-z-w等形态的解析规则如i686-linux-android的 oslinux、envandroid。freebsd 构建freebsd-builds-template.yaml 通过vmactions/freebsd-vmv1在 FreeBSD 14.0 虚拟机内以非 root 用户运行ci/freebsd/script.bash覆盖 FreeBSD 目标注意其skip-main/skip-stable过滤的是整个 job 而非单个目标。全部 feature 组合验证all-features-template.yaml 在 ubuntu 与 windows 两个宿主上用cargo check-all-features --root-only验证所有 feature 组合可编译RUSTFLAGS: -D warnings它与主流程独立不自我测试安装脚本。格式与 lintcentos-fmt-clippy-template.yaml 负责 centos:7 容器内ci/raw_init.sh兼容性检查、shellcheck、oxfmt前端格式、taploTOML 格式、nightly rustfmt 与 clippy-D warnings同时校验模板重新生成的 CI 文件无 diff。总结一份可执行的新目标支持清单将文档与仓库实现结合为 rustup 新增一个带 host tools 的 Tier 2 目标完整步骤如下阶段动作涉及文件提交形态告知 rustup在matrix.target中添加目标行附加# skip-pr skip-main skip-stableci/actions-templates/linux-builds-template.yaml正式提交必要时补充 dev 配置若目标可在托管 runner 原生跑测试在matrix.include中补mode: dev条目同上正式提交重新生成 CI运行./ci/actions-templates/gen-workflows.sh并提交生成的.github/workflows/ci.yamlci/actions-templates/gen-workflows.sh正式提交稳定目标移除skip-stable通常仅此一项ci/actions-templates/linux-builds-template.yaml正式提交PR 验证在单独临时 commit 移除skip-pr待 CI 绿后贴链接验证再丢弃该 commit同上临时提交验证后丢弃若目标是 Windows / macOS 平台则在动手前先通过专门的 rustup issue 与团队讨论方案。掌握这套流程即可让 rustup 对 Rust 官方新增的 Tier 2 平台保持同步支持持续产出对应平台的官方rustup-init构建产物。赞分享开发工具【免费下载链接】rustupThe Rust toolchain installer项目地址https://gitcode.com/gh_mirrors/ru/rustup点击查看免费下载相关推荐描述描述 添加了对ARM架构musl工具链的支持解决 1234 实现细节 修改toolchain探测逻辑添加aarch64 unknown linux musl开发工具rustup 开发者指南dev-guidemdBook 文档构建与 rustup 开发贡献全流程实践rustup 开发者指南dev guidemdBook 文档构建与 rustup 开发贡献全流程实践 doc/dev guide/README.md 是开发工具Rustup跨平台开发Windows、Linux与macOS全支持Rustup跨平台开发Windows、Linux与macOS全支持 引言跨平台开发的痛点与解决方案 你是否曾因不同操作系统间的工具链差异而困扰在Windo开发工具上一篇Beeftext完全指南Windows终极文本片段工具让输入效率提升10倍下一篇Citra模拟器终极指南在PC上完美运行3DS游戏创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 rustup 开发者指南：如何为 rustup 新增带 Host Tools 的 Tier 2 目标平台（Recipes）
开发工具【免费下载链接】rustupThe Rust toolchain installer项目地址https://gitcode.com/gh_mirrors/ru/rustup点击查看免费下载本文对应 rustup 仓库 开发指南 中的 Recipes 章节recipes.md。当 Rust 官方将一个目标平台target提升为带 host tools 的 Tier 2后rustup 就需要为其提供官方构建产物。本文完整讲解从告知 rustup 新目标到在 CI 中稳定启用该目标的完整流程并结合仓库中的 CI 模板、脚本与测试源码说明每一步背后的实现机制。读完本文你将掌握如何在linux-builds-template.yaml中登记新目标、skip-*注释的精确语义、如何在 PR 中临时启用 CI 验证以及如何判断何时可以移除skip-stable让新目标进入稳定发布。背景什么是带 Host Tools 的 Tier 2 目标Rust 官方按支持程度将目标平台划分为若干 tier。rustup 的原则是所有带 host tools 的 target tuple 都应当被 rustup 识别并拥有官方 rustup 构建产物如rustup-init、各平台发行包。所谓带 host tools指该平台不仅能交叉编译 Rust 程序还具备运行编译器、执行测试等宿主能力。因此一旦某个新目标被提升为 tier 2 with host toolsrustup 就应通过下述两步流程显式支持它Informing rustup告知 rustup 新目标的存在把目标加入构建矩阵但先在所有 CI 场景中禁用其构建Stabilizing稳定该目标当该目标在 stable Rust 中可用后按目标热度逐步在特定 CI 场景中启用。第一步告知 rustup 新目标Linux 交叉编译场景为什么聚焦 Linux截至本文写作时GitHub Actions 的 runner 原生支持 Linux、Windows 和 macOS 三个宿主系统。Tier 2 的构建大多通过从 Linux 交叉编译完成只有 Windows 与 macOS 目标在对应宿主机上直接编译。因此文档与本节重点讲解 Linux 场景Windows / macOS 新增目标的处理方式见下文专门小节。在 CI 模板中登记目标需要修改的核心文件是 ci/actions-templates/linux-builds-template.yaml。在strategy.matrix.target列表中为你的新目标增加一行例如target: - x86_64-unknown-linux-gnu - armv7-unknown-linux-gnueabihf # ... 其他已有目标 ... - your-new-target-tuple # skip-pr skip-main skip-stable关键点在于登记新目标时必须在本行末尾追加 YAML 注释# skip-pr skip-main skip-stable以在所有场景中禁用该目标的构建。此时新增目标只是被 rustup 知晓并不会真正进入任何 CI 构建流程。关于 skip 关键字的一个细节原文档中写作skip-master而当前仓库 linux-builds-template.yaml 中实际使用的关键字是skip-main例如aarch64-unknown-linux-musl # skip-pr skip-main、aarch64-unknown-freebsd # skip-pr skip-main skip-stable。这是模板演进过程中的命名差异动手修改时请以仓库中现行关键字为准。三个场景关键字分别为skip-prPR 场景、skip-mainmain 分支场景、skip-stablestable 分支场景。skip 注释是如何生效的模板生成机制你可能好奇 YAML 注释怎么会影响 CI 行为奥秘在于 ci/actions-templates/gen-workflows.shrustup 的正式工作流文件.github/workflows/ci.yaml不是手写的而是由模板脚本生成的。该脚本的核心逻辑gen_job () { grep -v skip-$2 $INPATH/$1-template.yaml $OUTPATH }即生成某个场景如pr、main、stable的 job 时用grep -v过滤掉模板中所有包含对应skip-*注释的行。因此生成 PR 场景gen_job linux-builds pr时# skip-pr所在行会被剔除生成 main 场景时# skip-main所在行被剔除生成 stable 场景时# skip-stable所在行被剔除。一行# skip-pr skip-main skip-stable意味着该目标在所有三个场景中都被过滤从而在所有场景禁用构建。同理移除某个skip-*就等于在对应场景中重新启用该目标。脚本还展示了完整的生成顺序依次调用windows-buildspr/main/stable、linux-buildspr/main/stable、macos-builds按 x86_64/aarch64 拆分、freebsd-buildsmain/stable以及centos-fmt-clippy、all-features、test-docs三个单 job最后通过conclusion汇总所有带# job-name标记的 job 到needs列表见 conclusion-template.yaml。所以修改任何模板后都需要重新运行./ci/actions-templates/gen-workflows.sh来重新生成工作流——这一点由 centos-fmt-clippy-template.yaml 中的 Run CI workflow generation checks 步骤自动校验运行脚本后git diff --exit-code若生成结果与已提交的工作流不一致则 CI 失败。构建矩阵的组织方式以 linux-builds-template.yaml 为例Linux 构建矩阵按以下方式组织matrix.mode目前固定为release每个目标都做 release 构建matrix.target目标平台列表含 x86_64-unknown-linux-gnu、armv7-unknown-linux-gnueabihf、aarch64-linux-android、各 BSD/Solaris/illumos、powerpc 系列、s390x、riscv64gc、loongarch64 等matrix.include为特定目标补充配置例如能在托管 runner 上原生运行测试的目标补充mode: dev此时会运行完整测试套件aarch64-unknown-linux-gnu使用ubuntu-24.04-armARM runnerAndroid 系列注释说明使用本地 docker 镜像见步骤中*-linux-android*分支带#snap_arch注释的目标预留了 snap 打包架构信息。登记新目标时除了在target列表加一行并附加# skip-pr skip-main skip-stable还需判断该目标是否满足测试套件可在托管 runner 上原生运行的条件以决定是否需要同步在include中添加mode: dev条目dev 模式走 ci/run.bash 的完整构建测试路径release 模式则只cargo build产出二进制并exit 0跳过测试。从告知到可构建的完整链路在 Linux 场景中模板里对该目标的构建最终会落到以下步骤见 linux-builds-template.yaml 的steps克隆仓库actions/checkoutv7fetch-depth: 0以便获取标签安装 rustup 自身sh ./rustup-init.sh --default-toolchainnone --profileminimal -y并保证 stable 工具链最新rustup target install $TARGET安装目标按目标选择 docker 镜像Android 用android本地镜像其余用目标 tuple 同名镜像见 ci/docker 目录下各 Dockerfilebash ci/fetch-rust-docker.bash ${TARGET}从 rust-lang/rust 拉取基础镜像若存在ci/docker/$DOCKER/Dockerfile则本地构建注意模板中特意禁用了 BuildKit规避 rustup 已知的 Docker 回归问题在 docker 内运行bash ci/run.bash设置BUILD_PROFILE、TARGET、SKIP_TESTS、INSTALL_BINDGEN1等环境变量release 模式下上传产物rustup-initactions/upload-artifactv7保留 7 天在 main/stable 分支的 push 上进一步执行ci/prepare-deploy.bash并上传到 S3dev-static-rust-lang-org/rustup/与rustup-builds/两个桶。其中 ci/run.bash 是实际构建脚本它会根据TARGET决定启用哪些 feature如reqwest-native-tls、vendored-openssl、reqwest-rustls-tls并对 aws-lc-rs 不支持的 powerpc*/mips*/loongarch*/netbsd*/illumos*/solaris* 平台跳过 rustls且对arm-linux-androideabi设置CFLAGS-marcharmv7。若SKIP_TESTS非空则只构建二进制后退出否则执行先全部构建、再全部测试的流程build_test build/RUSTUP_CI1 build_test test以缓解 7GB 内存 runner 上反复构建导致的换页问题。实践提示新增目标时建议对照一个已完成该流程的示例 PR。文档推荐的参考是 rustup#4688在 rustup 代码库中查找需要提及新目标的几乎所有位置的样例。注意本仓库为只读镜像实践时请在你的 rustup fork 上按上述步骤修改并提交 PR。第二步稳定目标Stabilizing何时以及如何启用当你的新目标在stable Rust中可用后就可以按目标的热门程度在特定 CI 场景中启用它了。具体操作是移除 linux-builds-template.yaml 中该行注释里的某些skip-*关键字。大多数情况下只需移除skip-stable即让该目标进入 stable 场景target: - your-new-target-tuple # skip-pr skip-main为什么通常只启 stable 场景从 linux-builds-template.yaml 顶部三个 job 的if条件可以看出stable 场景build-linux-stable不仅覆盖 stable 分支的 push还包含schedule定时触发与workflow_dispatch手动触发是发布与日常验证的核心场景而 PR 与 main 场景更偏日常开发对尚不成熟的新目标可以继续跳过。PR 验证流程先临时启用再正式合并文档特别强调为稳定目标创建 PR 时需要证明该目标在 CI 中确实能通过具体做法在单独的 commit中移除skip-pr临时在该 PR 的 CI 中启用这个目标等待该 PR 的 CI 变绿把该次 CI 运行的链接贴到 PR 讨论中供维护者验证文档给出的示例是 rustup#4816 的评论验证通过后安全地丢弃这个临时 commit如git rebase/ 交互式 rebase 删除该提交恢复skip-pr状态让 PR 具备合并条件。这一临时启用—验证—回滚的节奏既能在合并前拿到真实构建证据又不会在正式历史中引入未稳定的目标。请注意不要将临时提交与真实修改混在一起提交否则回滚时会把登记/启用逻辑一并删掉。Windows 与 macOS 新目标的处理文档明确说明如果需要支持新的 Windows 或 macOS 目标请在一个专门的 rustup issue 中与团队讨论而不是照搬 Linux 流程。原因从模板结构可以推断Windows 目标在 windows-builds-template.yaml 中直接于 Windows runner含windows-11-arm上编译涉及 MSVC/GNU/gnullvm 三种 ABI、NASM构建 aws-lc-rs 需要、mingw 与 llvm-mingw 工具链安装等复杂步骤且配置了RUSTFLAGS: -Ctarget-featurecrt-static静态链接策略macOS 目标在 macos-builds-template.yaml 中按架构拆分 jobbuild-macos-aarch64与build-macos-x86_64并各自设置MACOSX_DEPLOYMENT_TARGETaarch64 为 11.0x86_64 为 10.12release 构建还会用otool -L校验动态链接不含/usr/local路径。这两类目标由于涉及宿主工具链、签名与发布流程的特殊性不适合单凭模板加一行完成因此与团队先行沟通是必要的。相关验证与配套设施除构建矩阵外rustup 对目标平台还有一套配套校验新增目标时可一并关注target tuple 识别测试tests/suite/known_target_tuples.rs 中的gen_known_target_tuples测试会根据platformscrate 的Platform::ALL重新生成src/dist/target_tuple/known.rs架构/OS/环境三元组列表若与现有生成文件不一致则原地更新并报错。这印证了所有目标 tuple 都应为 rustup 所识别的原则——你的新目标需要能被正确解析为 arch / os / env 三段式该文件注释详述了x-y-z-w等形态的解析规则如i686-linux-android的 oslinux、envandroid。freebsd 构建freebsd-builds-template.yaml 通过vmactions/freebsd-vmv1在 FreeBSD 14.0 虚拟机内以非 root 用户运行ci/freebsd/script.bash覆盖 FreeBSD 目标注意其skip-main/skip-stable过滤的是整个 job 而非单个目标。全部 feature 组合验证all-features-template.yaml 在 ubuntu 与 windows 两个宿主上用cargo check-all-features --root-only验证所有 feature 组合可编译RUSTFLAGS: -D warnings它与主流程独立不自我测试安装脚本。格式与 lintcentos-fmt-clippy-template.yaml 负责 centos:7 容器内ci/raw_init.sh兼容性检查、shellcheck、oxfmt前端格式、taploTOML 格式、nightly rustfmt 与 clippy-D warnings同时校验模板重新生成的 CI 文件无 diff。总结一份可执行的新目标支持清单将文档与仓库实现结合为 rustup 新增一个带 host tools 的 Tier 2 目标完整步骤如下阶段动作涉及文件提交形态告知 rustup在matrix.target中添加目标行附加# skip-pr skip-main skip-stableci/actions-templates/linux-builds-template.yaml正式提交必要时补充 dev 配置若目标可在托管 runner 原生跑测试在matrix.include中补mode: dev条目同上正式提交重新生成 CI运行./ci/actions-templates/gen-workflows.sh并提交生成的.github/workflows/ci.yamlci/actions-templates/gen-workflows.sh正式提交稳定目标移除skip-stable通常仅此一项ci/actions-templates/linux-builds-template.yaml正式提交PR 验证在单独临时 commit 移除skip-pr待 CI 绿后贴链接验证再丢弃该 commit同上临时提交验证后丢弃若目标是 Windows / macOS 平台则在动手前先通过专门的 rustup issue 与团队讨论方案。掌握这套流程即可让 rustup 对 Rust 官方新增的 Tier 2 平台保持同步支持持续产出对应平台的官方rustup-init构建产物。赞分享开发工具【免费下载链接】rustupThe Rust toolchain installer项目地址https://gitcode.com/gh_mirrors/ru/rustup点击查看免费下载相关推荐描述描述 添加了对ARM架构musl工具链的支持解决 1234 实现细节 修改toolchain探测逻辑添加aarch64 unknown linux musl开发工具rustup 开发者指南dev-guidemdBook 文档构建与 rustup 开发贡献全流程实践rustup 开发者指南dev guidemdBook 文档构建与 rustup 开发贡献全流程实践 doc/dev guide/README.md 是开发工具Rustup跨平台开发Windows、Linux与macOS全支持Rustup跨平台开发Windows、Linux与macOS全支持 引言跨平台开发的痛点与解决方案 你是否曾因不同操作系统间的工具链差异而困扰在Windo开发工具上一篇Beeftext完全指南Windows终极文本片段工具让输入效率提升10倍下一篇Citra模拟器终极指南在PC上完美运行3DS游戏创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考