Fix Rust build example configuration handling#11584
Conversation
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
📌 Code Review Assignment🏷️ Tag: bsp_rt-sparkChanged Files (Click to expand)
🏷️ Tag: bsp_stm32Reviewers: @Liang1795 @hamburger-os @wdfk-prog Changed Files (Click to expand)
🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2026-07-09 22:57 CST)
📝 Review Instructions
|
|
|
这个有ci可以看护起来吗？ |
|
这个要给具体的BSP添加ci-attach功能，让gihub的ci检测到然后把rust组件添加到构建系统中进行编译看护 |
yanhu7150-tech
requested review from
Rbb666,
kurisaW and
supperthomas
as code owners
github-actions
Bot
added
BSP: STM32
yanhu7150-tech
force-pushed
the
bugfix-rust-build-target-artifact
branch
from
d3bd2a3 to
22fbb3f
Compare
已经按照您的建议补充 Rust CI 编译看护。
|
这个失败看起来发生在 |
Add a rust attach config to the stm32f407-rt-spark BSP so CI enables the Rust core and component-log example on a Cortex-M4 target. The Rust toolchain setup is scoped to this attach configuration so unrelated BSP build jobs are not affected.
yanhu7150-tech
force-pushed
the
bugfix-rust-build-target-artifact
branch
from
22fbb3f to
f89e400
Compare
|
我已经通过最小改动修复了 |
|
已根据 CI 结果进一步修复 Rust attach 相关构建问题。
|
3 participants
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
本 PR 修复 RT-Thread Rust 构建脚本中多处配置处理不一致的问题，主要涉及 Rust core、Rust application examples、Rust component examples、Rust module examples 的构建入口、Cargo 产物识别、Kconfig 选项门控、Cargo feature 传递、Rust target 推断、Cargo 失败诊断以及 SCons 链接参数生成。
原有实现中，部分 Rust 构建路径存在 Kconfig 配置、Cargo 实际产物和 SCons 链接设置不一致的问题。在特定配置组合下，可能导致 Rust 示例被错误跳过、使用错误的链接库名、向 Cargo 传入 manifest 未声明的 feature、在 Rust artifact 未生成时仍加入 SCons group，或者在缺少底层系统能力时仍构建相关 Rust example。这些问题会影响 Rust 构建系统在不同 BSP、不同 Rust target 和不同 example 配置组合下的稳定性、可诊断性和配置一致性。
本 PR 主要解决以下问题：
原有部分构建脚本会根据固定名称推断 Rust staticlib 的链接名，而不是根据 Cargo 实际生成的 artifact 反推出 SCons
LIBS中应使用的库名。当 Cargo package name、lib name 或实际 artifact 名称和脚本假设不一致时，可能出现 Cargo 构建成功，但 SCons 链接阶段使用错误-lxxx的问题。原有 target 检测逻辑对部分 RISC-V fallback 和 Cortex-M 变体覆盖不足。例如 Cortex-M0、Cortex-M0+、Cortex-M23、Cortex-M85 等目标可能被推断为不合适的 Rust target，导致 Cargo target 与实际 MCU 架构不匹配。
RT_RUST_CORE是 Rust core library 的配置开关，但原有components/rust/core/SConscript对该开关的约束不完整。在 Rust core staticlib 未成功生成、Rust toolchain 不存在、Rust target 未安装或 target 检测失败时，仍可能把rust_cmd.c加入 SCons group，导致后续链接阶段进入无效链接路径或产生符号风险。部分 example 的 SConscript 或 build helper 没有严格遵守 Kconfig 语义。例如 module example 的子开关未被正确用于选择模块示例；component example 的总开关
RT_RUST_BUILD_COMPONENTS曾被RUST_LOG_COMPONENT子开关错误门控；RT_RUST_BUILD_ALL_EXAMPLES可能绕过部分 example 所需的底层依赖检查；loadlibexample 依赖RT_USING_MODULE，但原有 build-all 路径可能仍尝试构建；fsexample 会引用 POSIX 文件 API，但原有逻辑未确认 DFS/POSIX 文件层是否可用。部分 Rust component/application 的 feature 传递逻辑不完整。例如
RUST_LOG_COMPONENT对应的enable-logfeature 需要正确传递给 component registry；fsapplication 使用日志组件时需要补齐对应 feature；component 构建时不应把 manifest 未声明的 feature 传给 Cargo，否则 Cargo 会因为 unknown feature 失败。原有脚本在部分 Cargo 失败或 Cargo 不存在的场景下，错误输出不够完整，不利于用户定位 Rust toolchain、Rust target 或 Cargo manifest 问题。
综上，本 PR 主要修复 Rust 构建系统中的普通软件缺陷，使 Rust core、Rust application example、Rust component example 和 Rust module example 的构建行为更加符合 Kconfig 配置语义，并提高 Cargo 构建、artifact 查找和 SCons 链接过程的一致性与可诊断性。
你的解决方案是什么 (what is your solution)
本 PR 对 Rust 构建脚本做了以下修复：
在 Rust core、component registry、user application 等构建路径中，根据实际生成的 staticlib artifact 反推链接库名，避免固定假设
libxxx.a名称导致 SConsLIBS与真实 Cargo 产物不一致。改进 RISC-V fallback 逻辑，根据
-march/-mabi等编译参数推断更合适的 Rust target。同时补充 Cortex-M 系列目标映射，包括：thumbv6m-none-eabithumbv8m.base-none-eabithumbv8m.main-none-eabi这样可以避免部分 Cortex-M 目标被错误映射到不合适的 Rust target。
components/rust/core/SConscript现在会正确遵守RT_RUST_CORE配置。当 Rust toolchain 不存在、target 检测失败、target 未安装或 Rust core staticlib 未成功生成时，不再把rust_cmd.c加入 SCons group，避免在 Rust core artifact 不存在时继续进入无效链接路径。module example 的构建选择现在会遵守对应 Kconfig 子开关，例如
RT_RUST_MODULE_SIMPLE_MODULE。这样启用 Rust module example 总开关时，不会忽略具体 module example 的子配置。RT_RUST_BUILD_COMPONENTS是 component example 的总开关，RUST_LOG_COMPONENT只是 log component 自动初始化相关子开关。修复后，RT_RUST_BUILD_COMPONENTS=y时，即使RUST_LOG_COMPONENT=n，component example 仍可正常进入构建流程；RUST_LOG_COMPONENT只继续影响对应 Cargo feature，而不再错误地控制整个 component example 是否构建。对需要底层系统能力的 Rust application example 增加构建前依赖判断：
loadlib依赖RT_USING_MODULE。未启用 module 支持时，即使RT_RUST_BUILD_ALL_EXAMPLES=y，也不会构建loadlib。fs依赖 POSIX 文件 API。只有满足以下任一条件时才构建：RT_USING_POSIX_FS=yRT_USING_DFS=y && DFS_USING_POSIX=yRT_USING_DFS=y && RT_USING_DFS_V2=y这样可以避免 Rust application staticlib 通过
--whole-archive被强制链接后引用缺失的底层 C 符号。本 PR 对 component/application 的 Cargo feature 处理进行了收敛和校验：
RUST_LOG_COMPONENT -> enable-log的 feature 映射；fsapplication 自动补齐日志相关 feature，保证其源码、Cargo manifest 和构建命令保持一致。rt-rust依赖路径修复
components/rust/examples/modules/example_lib/Cargo.toml中rt-rust依赖路径，使其指向实际的 Rust core crate。在 Cargo 执行失败或 Cargo 不存在时，输出更明确的错误信息和 Cargo stdout/stderr，方便用户定位 toolchain、target 或 manifest 问题。
整体上，本 PR 只修改 Rust 构建脚本、Rust example 构建入口和一个 Rust module example 的 Cargo 依赖路径，不修改 BSP、驱动、内核调度或运行时业务逻辑。
请提供验证的bsp和config (provide the config and bsp)
本 PR 修改范围为 Rust 构建脚本和 Rust example 构建配置处理，不针对特定 BSP 修改运行时代码，因此没有限定单一验证 BSP。
本地验证主要覆盖以下 Rust 构建路径：
验证方式为本地构建脚本回归验证和静态编译检查，覆盖 Rust core、application example、component example、module example 的配置组合、Cargo 命令生成、artifact 查找、LIBS/LIBPATH/LINKFLAGS 生成和失败路径处理。
本 PR 未要求固定某一个 BSP 的
.config。验证时覆盖了以下 Rust 相关配置组合：重点验证场景包括：
本地验证结果如下：
说明：上述回归验证用于检查 Rust 构建脚本行为，包括 SConscript mock、fake Cargo 命令捕获、Cargo manifest 检查、link flag 生成检查和失败路径检查。PR 中未提交额外大型测试文件，避免引入与本次修复无关的测试体积。
GitHub Actions 已通过。当前 PR 检查结果为 103 successful checks，2 skipped checks，页面状态显示 All checks have passed。
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up