OHOS cross-build fails on Windows (aws-lc-sys CMake uses the Visual Studio generator) and codewhale-cli then fails E0433 #6988

Environment

• Host: Windows, Visual Studio 17 2022 BuildTools (MSVC 19.44.35215.0), CMake 3.31.5, ninja on PATH
• DevEco OpenHarmony native SDK 26.0.0 via OHOS_NATIVE_SDK
• Target: aarch64-unknown-linux-ohos (rustup target installed)
• Reproduced with the documented flow from docs/HarmonyOS.md: set OHOS_NATIVE_SDK, dot-source scripts/ohos-env.ps1, then
  cargo build --release --target aarch64-unknown-linux-ohos -p codewhale-cli

Failure 1 - aws-lc-sys v0.45.0 build script panics

error: failed to run custom build script for `aws-lc-sys v0.45.0`
-- Building for: Visual Studio 17 2022
-- The C compiler identification is MSVC 19.44.35215.0
-- Check for working C compiler: .../cl.exe - broken
cl : command line error D8021: invalid numeric argument '/Wa,--noexecstack'

aws-lc-sys builds through the cmake crate, which passes no -G. On Windows, CMake then
defaults to the Visual Studio generator. That generator ignores the clang compiler that
ohos.toolchain.cmake sets via CMAKE_C_COMPILER, uses cl.exe instead, and still applies the
toolchain's clang-only flags (-Wa,--noexecstack, --target=..., --sysroot=...), which
cl.exe rejects. scripts/ohos-env.ps1 exports CMAKE_TOOLCHAIN_FILE_aarch64_unknown_linux_ohos
but no generator. On Linux/macOS the default generator is Unix Makefiles, which honours the
toolchain, so non-Windows CI never hit this.

Failure 2 - codewhale-cli no longer compiles for OHOS once failure 1 is fixed

error[E0433]: cannot find `update` in the crate root
  --> crates/cli/src/cloud/work.rs:236:33
note: found an item that was configured out
  --> crates/cli/src/lib.rs:9:5

mod update is #[cfg(not(target_env = "ohos")], but three call sites reference
crate::update::sha256_hex without the same gate:

• crates/cli/src/cloud.rs:1501 - SHA-256 verification of a downloaded account file
• crates/cli/src/cloud.rs:1962 - dispatch stamp seed digest
• crates/cli/src/cloud/work.rs:236 - Work task-context digest verification

The first and third are content-integrity checks, so they must stay compiled on OHOS and cannot
simply be cfg'd out. CI compile-checks codewhale-tui for the OHOS target but not
codewhale-cli, which is why this regressed unnoticed.

Proposed fix

1. scripts/ohos-env.ps1: export CMAKE_GENERATOR=Ninja, falling back to the SDK-bundled
   build-tools/cmake/bin/ninja.exe and failing loudly when neither exists.
2. Move sha256_hex/hex_bytes out of the cfged update module into an ungated crate::hashing
   module in codewhale-cli (same implementation the TUI already shares through
   codewhale_runtime::hashing) and point the three call sites at it.

Verified on Windows with the SDK above: aws-lc-sys builds in about 43 s and
cargo build --release --target aarch64-unknown-linux-ohos -p codewhale-cli exits 0, producing
an ELF64 AArch64 PIE that needs only libc.so and libtime_service_ndk.so. Host-target
cargo check -p codewhale-cli and cargo check -p codewhale-cli --tests both exit 0, and
cargo fmt --all -- --check exits 0.

A fix PR follows this issue (#6989).

中文说明

环境：Windows + Visual Studio 17 2022 BuildTools(MSVC 19.44.35215.0)、CMake 3.31.5、PATH 中有 ninja;DevEco OpenHarmony native SDK 26.0.0(通过 OHOS_NATIVE_SDK 指定)；目标 aarch64-unknown-linux-ohos。按 docs/HarmonyOS.md 文档流程复现：设置 OHOS_NATIVE_SDK、dot-source scripts/ohos-env.ps1,然后执行 cargo build --release --target aarch64-unknown-linux-ohos -p codewhale-cli。

问题一:aws-lc-sys v0.45.0 构建脚本直接 panic。 它通过 cmake crate 构建,而该 crate 不传 -G 参数;Windows 上 CMake 于是默认选中 Visual Studio 生成器——这个生成器会无视 ohos.toolchain.cmake 里通过 CMAKE_C_COMPILER 指定的 clang,强行使用 cl.exe,同时又应用工具链里那些只属于 clang 的参数(-Wa,--noexecstack、--target=...、--sysroot=...),cl.exe 无法解析,报 D8021。scripts/ohos-env.ps1 只导出了 CMAKE_TOOLCHAIN_FILE_aarch64_unknown_linux_ohos,没有指定生成器。Linux/macOS 上默认生成器是 Unix Makefiles,会遵循工具链,所以非 Windows 的 CI 从来没有暴露过这个问题。

问题二:问题一修好后,codewhale-cli 在 OHOS 目标上编译不过(E0433)。 mod update 带有 #[cfg(not(target_env = "ohos"))],但有三处调用没有加同样的门控就直接引用 crate::update::sha256_hex:

• crates/cli/src/cloud.rs:1501 —— 校验下载的账户文件 SHA-256
• crates/cli/src/cloud.rs:1962 —— dispatch stamp 种子摘要
• crates/cli/src/cloud/work.rs:236 —— Work 任务上下文摘要校验

第一处和第三处是内容完整性校验,在 OHOS 上必须保留,不能简单 cfg 掉。CI 对 OHOS 目标只检查 codewhale-tui、不检查 codewhale-cli,所以这个回退一直没被发现。

修复方案:

1. scripts/ohos-env.ps1 导出 CMAKE_GENERATOR=Ninja;PATH 里没有 ninja 时回退到 SDK 自带的 build-tools/cmake/bin/ninja.exe,两者都没有则明确报错退出。
2. 把 sha256_hex/hex_bytes 从被门控的 update 模块移到 codewhale-cli 中未门控的 crate::hashing 模块(与 TUI 已在使用的 codewhale_runtime::hashing 实现一致),三处调用改指新位置。

已验证(Windows + 上述 SDK):aws-lc-sys 约 43 秒构建成功;cargo build --release --target aarch64-unknown-linux-ohos -p codewhale-cli 退出码 0,产物为 ELF64 AArch64 PIE,只依赖 libc.so 和 libtime_service_ndk.so;宿主目标 cargo check -p codewhale-cli 与 --tests 均退出码 0;cargo fmt --all -- --check 通过。修复 PR 见 #6989。