feat(frontend): add rust_mobile_library target

What changed

This adds a higher-level rust_mobile_library target kind to the Rust Starlark prelude. The target itself now records source and crate metadata, while Apple and Android consumers materialize only the native library variant they need.

The bundled mobile examples declare one SharedRust target instead of separate Apple and Android Rust targets. The generated graph tests assert that both apps depend on the same Rust target, that an Android app declares only the Android Rust compile action, and that Apple and Android consumers receive the expected native provider fields.

The guide and reference pages document the new target kind, including the current limitation that rust_mobile_library does not support Rust dependencies yet. The android_abi field is documented as the Android Application Binary Interface.

Why

A single Rust dependency can be consumed by both Apple and Android app targets in the same graph. A target-local configurable crate_type or target selection cannot know which consumer is asking for the dependency, so the mobile shape needs to be represented as one higher-level rule with consumer-owned platform outputs.

Root cause

The first implementation declared both platform Rust compile actions while analyzing the shared dependency. That meant an Android-only consumer still required the Apple Rust target, and an Apple-only consumer still required the Android linker.

It also reused one resolved Rust dependency provider set for both platform compiles. Those provider records contain compiled Rust artifacts for one target triple, so sharing them across Apple and Android would mix incompatible compiled dependency outputs.

Approach

The Starlark prelude now exposes generic native-dependency materialization hooks. The Rust prelude overrides those hooks for rust_mobile_library, so Apple consumers compile the staticlib variant and Android consumers compile the cdylib variant only when they collect native dependencies.

Each materialized variant keeps the original SharedRust label in the provider, but uses consumer-owned output and scratch directories under rust-mobile/<target>/<platform>/. The action identifiers remain platform-specific, such as SharedRust:rustc:apple and SharedRust:rustc:android.

Until target-specific Rust dependency resolution exists for this rule, rust_mobile_library rejects Rust dependencies. Projects that need Rust dependencies can keep using explicit platform-specific rust_library targets.

Impact

Android-only graphs no longer require Apple Rust targets, and Apple-only graphs no longer require the Android linker. The behavior remains implemented in Starlark target kinds and helper hooks, without adding toolchain-specific branches to the Rust engine.

The new target kind still does not advertise rust_crate, because it does not produce one reusable rlib for downstream Rust compilation.

Validation

• mise exec -- cargo test -p once-frontend --test prelude
• mise exec -- cargo test -p once-frontend --test examples
• mise exec -- cargo test -p once-frontend
• mise exec -- cargo fmt --all -- --check

No GitHub comments yet.