From 1297e3259b49174a633705eeef10ce8e5d80fce7 Mon Sep 17 00:00:00 2001 From: Duncan Tourolle Date: Sat, 22 Aug 2026 21:23:52 +0200 Subject: [PATCH] Stop claiming the app crates cannot cross-compile MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The note above the core-crate check said the UI and app crates would join "once the Android shell exists". They already had. Building `darkroom-android` for aarch64 takes 4m23s and produces `libdarkroom.so`, linked for Android 28 — which is what the step below now checks, and what a device installs. Rewritten to say what the core check is actually for: a fast, link-free gate that fails early and names a smaller suspect, ahead of the full build. Co-Authored-By: Claude Opus 5 (1M context) --- .gitea/workflows/build-and-test.yml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/.gitea/workflows/build-and-test.yml b/.gitea/workflows/build-and-test.yml index 467fa17..e1dd17d 100644 --- a/.gitea/workflows/build-and-test.yml +++ b/.gitea/workflows/build-and-test.yml @@ -94,8 +94,15 @@ jobs: target-android key: android-${{ hashFiles('**/Cargo.lock') }} - # Only the core crates cross-compile today; the UI and app crates join - # once the Android shell exists (milestone v0.1, FR-PLAT-AND-*). + # A fast gate on the crates most likely to break the cross-compile, run + # before the expensive part. It is `cargo check`, so it type-checks + # without linking and returns in a fraction of the time the step below + # takes. + # + # Not a statement that only these crates cross-compile — `darkroom-android` + # and the whole UI stack beneath it build for aarch64 too, which is what + # the API-level step below does. This one exists to fail fast and name a + # smaller suspect when it does. - name: Cross-compile core env: CARGO_TARGET_DIR: target-android