feat: cross-compilation and multi-target hew builds

[slepp]

Summary

Enable hew to cross-compile programs for any supported target from a single host, similar to GOOS=windows go build. This also simplifies the release pipeline by eliminating the need for native CI runners on every platform.

Background

Building Hew programs for a different native target requires a native toolchain on the target platform because:

1. libhew.a (the runtime) must be built for the target — requires cargo build --target <triple>
2. The linker invocation in link.rs calls the system cc/clang, which only links for the host
3. find_hew_lib() has no target-aware path resolution for native architectures

Current state

Phase 1: Multi-target hew-codegen ✅ COMPLETE (PR #261)

• hew-codegen is now embedded in the hew binary via C API (no subprocess)
• LLVM is built with all target backends (AllTargetsCodeGens)
• Target triple wires through from CLI --target flag to LLVM via the C API
• WASM target (--target wasm32-wasip1) is production-ready with dedicated linker path
• Native cross-target code emission works (LLVM generates correct object files)

Phase 2: Pre-built libhew.a per target

• Cross-compile hew-lib for each supported target using Cargo cross-compilation
• Ship pre-built libhew.a archives per platform in the distribution (or download on demand)
• Store in lib/<target>/libhew.a (pattern already exists for WASM: lib/wasm32-wasip1/)

Phase 3: Universal linker via lld

• Replace platform cc with lld (LLVM linker) which handles all targets from a single binary
• link.rs selects the right libhew.a and platform libs based on --target
• find_hew_lib() needs target-aware path resolution
• User experience: hew build --target windows-x86_64 main.hew

Phase 4: Simplified release pipeline

• Build hew once on Linux with all LLVM targets
• Cross-link for every platform without native runners
• Native runners only needed for platform-specific testing, not building

Benefits

• Developers on macOS can build Windows/Linux binaries locally
• CI releases go from 3 hours (LLVM builds) to ~15 minutes
• Enables embedded/IoT targets (ARM, RISC-V) without dedicated hardware
• Aligns with the actor model vision — actors should be deployable anywhere

Prior art

• Go: GOOS=windows GOARCH=amd64 go build
• Zig: zig build-exe -target x86_64-windows
• Rust: cargo build --target x86_64-pc-windows-msvc (with linker toolchain)

[slepp]

v0.3.0 status audit

Inspected origin/main (de3a810) and recent PRs. Ground truth:

What has landed

Work	PR	Status
Embed hew-codegen, all LLVM target backends, target triple → LLVM via C API, WASM production target	#261	✅ merged
Staged cross-target output support	#540	✅ merged
--emit-obj cross-target proof: default object-output names from target suffix (no -o required), early rejection of foreign native-link with a clear --emit-obj redirect, e2e tests verifying object format + arch for arm64-apple-darwin / x86-linux-gnu / x86-windows-gnu	#730	✅ merged

Phase 1 of this issue is fully complete. The [Unreleased] CHANGELOG section did not reflect #730; PR #770 fixes that.

What is NOT done (deferred post-v0.3.0)

• Phase 2 – pre-built libhew.a archives per target (lib/<triple>/libhew.a), cross-compiled Cargo builds
• Phase 3 – universal linker via lld; link.rs + find_hew_lib() target-aware path resolution
• Phase 4 – simplified release pipeline (build once on Linux, cross-link everywhere)

Phases 2–4 require non-trivial CI infrastructure, lld integration, and multi-platform distribution work that is not safely shippable for v0.3.0.

Recommendation

Close or narrow this issue to "Phase 1 complete / --emit-obj prototype lane". Open a follow-on for Phases 2–4 against a post-v0.3.0 milestone. The v0.3.0 release ships the --emit-obj cross-target prototype as the honest deliverable.

[slepp]

I investigated the current state of this on main.

What is already true today:

• --target drives TargetSpec, target-aware find_hew_lib(<triple>), clang -target, and the Darwin -isysroot / deployment-target rewrite path.
• The current cross-target e2e coverage proves object emission for arm64-apple-darwin, x86_64-unknown-linux-gnu, and x86_64-pc-windows-gnu.
• What we have today is cross-target object support, not general host!=target native executable linking.

What still remains:

• native executable linking is still host-only
• lib/<triple>/libhew.a lookup exists, but the populated symlink/install story is still host-oriented
• the Windows ABI/toolchain choice is still unresolved (gnu object prototype vs msvc release lane)
• the Darwin sysroot / deployment-target / libc++ ABI contract is still implicit instead of frozen

My take is that this issue should be narrowed or split instead of executed as one monolithic lane. The cleanest next slices look like:

1. freeze/document the supported matrix as host-native executables + wasm, with cross-target objects only
2. a dedicated Linux ELF cross-link spike
3. a separate Windows ABI choice spike

That would make the remaining work testable and keep this from mixing target libhew distribution, cross-link toolchains/sysroots, Windows ABI policy, and release-pipeline concerns into one umbrella.