Hunter B
23c9481af1
Harvest the HarmonyOS/OpenHarmony port from PR #2634 and make it publish-safe by target-gating unsupported host dependencies out of the OHOS TUI graph. Self-update is disabled on OHOS, PTY shell mode reports unsupported, and Starlark execpolicy parsing returns an explicit unsupported-platform error until upstream starlark/rustyline/nix support catches up. Add OHOS SDK setup docs and launcher scripts, install the rustls ring provider for rustls-no-provider entrypoints, and keep the packaged codewhale-tui OHOS graph free of starlark, rustyline, nix@0.28, portable-pty, and arboard. Validation: cargo fmt --all -- --check; git diff --check; git diff --cached --check; cargo check -p codewhale-cli --locked; cargo check -p codewhale-app-server --locked; cargo check -p codewhale-tui --locked; cargo test -p codewhale-cli --locked update::tests::; cargo test -p codewhale-release --locked; cargo test -p codewhale-tui --locked background_tty_command_has_controlling_terminal; cargo test -p codewhale-tui --locked clipboard; cargo package -p codewhale-tui --allow-dirty --no-verify --locked; packaged OHOS cargo tree checks. OHOS target check still requires a loaded OpenHarmony SDK/sysroot and currently stops in ring with missing assert.h when CC/CFLAGS/linker are unset. Harvested from PR #2634 by @shenjackyuanjie. Co-authored-by: shenjackyuanjie <54507071+shenjackyuanjie@users.noreply.github.com>
2.1 KiB
HarmonyOS and OpenHarmony
This page covers CodeWhale on HarmonyOS PC and OpenHarmony cross-build setups.
Running On HarmonyOS PC
HarmonyOS PC can use the normal Linux ARM64 package when its userspace is glibc-compatible:
npm i -g codewhale
codewhale --version
You can also download codewhale-linux-arm64 and
codewhale-tui-linux-arm64 from the GitHub Releases page and place both
binaries on PATH.
Cross-Compiling To OpenHarmony
The repository does not check in machine-specific SDK paths. Set
OHOS_NATIVE_SDK to the OpenHarmony native SDK directory, the directory that
contains llvm/bin, sysroot, and build/cmake/ohos.toolchain.cmake.
On Windows PowerShell:
$env:OHOS_NATIVE_SDK="<path-to-openharmony-native-sdk>"
. .\scripts\ohos-env.ps1
rustup target add aarch64-unknown-linux-ohos
cargo build --target aarch64-unknown-linux-ohos -p codewhale-cli
On Linux or macOS:
export OHOS_NATIVE_SDK=/path/to/openharmony/native
. ./scripts/ohos-env.sh
rustup target add aarch64-unknown-linux-ohos
cargo build --target aarch64-unknown-linux-ohos -p codewhale-cli
The setup scripts export Cargo's target-specific linker, AR, CC, CXX,
CFLAGS, CXXFLAGS, CARGO_ENCODED_RUSTFLAGS, CC_SHELL_ESCAPED_FLAGS, and
CMake toolchain variables for aarch64-unknown-linux-ohos.
Compiler Wrappers
For ad-hoc compiler calls, use the root wrappers. They read the same
OHOS_NATIVE_SDK variable and do not contain local paths.
Windows PowerShell:
.\ohos-clang.ps1 --version
.\ohos-clangxx.ps1 --version
Linux or macOS:
sh ./ohos-clang.sh --version
sh ./ohos-clangxx.sh --version
If you want to run the POSIX wrappers directly as ./ohos-clang.sh, make them
executable first:
chmod +x ./ohos-clang.sh ./ohos-clangxx.sh
Cargo Config
.cargo/config.toml intentionally does not set a checked-in linker path.
Cargo cannot expand environment variables inside linker or CMake toolchain
path values there, so those values are exported by scripts/ohos-env.ps1 and
scripts/ohos-env.sh instead.