|
1 | 1 | --- |
2 | 2 | subject: targets |
3 | | -status: active |
| 3 | +status: landed |
4 | 4 | --- |
5 | 5 |
|
6 | 6 | # SDK toolchains, the payload/engine seam, and openkal across iOS, Android and Web |
7 | 7 |
|
8 | | -**Status:** design. Items A and E1 are measured and merged; the rest is for |
9 | | -review before implementation. |
| 8 | +**Status:** implemented, in mcpp #612 (2026.9.11.4), xim-pkgindex #813 and |
| 9 | +#820, openkal #29 and #30, mcpp-index #393, and the new repository |
| 10 | +`mcpplibs/openkal-emscripten`. The design sections are kept as they were |
| 11 | +reviewed; where the implementation departed from them, the sections from "What |
| 12 | +the implementation found" onward record why. |
10 | 13 |
|
11 | 14 | **Scope.** Five items, in dependency order. The first is measured and only needs |
12 | 15 | writing down; the second removes something rather than adding; the third is the |
@@ -491,8 +494,8 @@ write it down. |
491 | 494 | | C: the engine stops knowing | delete `ndk_host_tag()`'s call site and the build still resolves, because the descriptor answered; and a malformed descriptor is refused naming the file | yes -- a descriptor naming `oddly/named/clang++` resolved there, a path no engine derivation produces; a non-string `platform_floor` was refused naming the file and the key | |
492 | 495 | | C: no flag day | a payload with no descriptor resolves exactly as today -- asserted against the released android-ndk | yes, against the installed r30 payload: with the file removed the resolution line and the effective triple are byte-identical | |
493 | 496 | | C: the floor and the defines travel | not in the original list, and each needs its own reading or it is carried by the frontend's | yes -- `platform_floor = "26"` gave `…-android26` while `meta/platforms.json` says 21; an added define appeared in the std module's command AND in its cache identity | |
494 | | -| D: iOS builds | macOS runner, `xim:llvm` plus the located SDK, artefact is Mach-O arm64 with the iOS platform in `LC_BUILD_VERSION` | yes -- `platform 2` (IOS) for the device and `platform 7` (IOSSIMULATOR) for both simulator rows, `minos 18.0`, `sdk 18.5` | |
495 | | -| D: the simulator runs | macOS runner, `mcpp run --target aarch64-ios-sim` prints `1-2-3` | yes, through the `runner` and `xim:apple-simulator-tools`; and separately under a bare `simctl spawn`, which is what proved a bundle is not needed | |
| 497 | +| D: iOS builds | macOS runner, `xim:llvm` plus the located SDK, artefact is Mach-O arm64 with the iOS platform in `LC_BUILD_VERSION` | yes -- `platform 2` (IOS) for the device and `platform 7` (IOSSIMULATOR) for both simulator rows, `minos 18.0`, `sdk 18.5`. Asserted by `ios-engine`, which fails when any of the three readings differs, an empty reading included | |
| 498 | +| D: the simulator runs | macOS runner, `mcpp run --target aarch64-ios-sim` prints `1-2-3` | yes, through the `runner` and `xim:apple-simulator-tools`; and separately under a bare `simctl spawn`, which is what proved a bundle is not needed. Asserted by `ios-engine`, which fails when the exit status is not 0 or the line is absent | |
496 | 499 | | D: the host surface is bounded | on a macOS runner with `xcode-select` pointing nowhere, both iOS rows fail with a message naming the SDK -- and no other row changes | THE CRITERION WAS WRONG AND WAS REPLACED. `DEVELOPER_DIR=/nonexistent` did not make the SDK unlocatable -- `xcrun` ignores an invalid developer directory and falls back -- so the iOS build SUCCEEDED and the step asserted nothing. The claim now lives where the SDK is genuinely absent: e2e 641 on every non-Apple host, with the refusal required to name the SDK, the `xcrun` command, the Command-Line-Tools note and the compiler, and to arrive before any payload is resolved | |
497 | 500 | | E1: Android shares the implementation | merged and green against the RELEASED engine: both ABIs build, objects name no C library symbol, and a program over openkal alone ran on an emulator | yes (openkal-linux 0.12.0) | |
498 | 501 | | E2: iOS reuses it | `openkal-macos` compiles for the three iOS rows on a macOS runner, and its objects name no C library symbol -- the same check the Android leg applies, against a third libc | the `cfg` line is in `examples/portable`; the compile leg belongs to openkal-macos's own CI and is not in this batch | |
@@ -729,6 +732,43 @@ file was written on, travelling as if it were a property of the scheme. The |
729 | 732 | fourth is a field the caller sets and the implementation must honour, and the |
730 | 733 | suite passes a deliberately short structure to find out. |
731 | 734 |
|
| 735 | +### A verified tier whose only check could not fail |
| 736 | + |
| 737 | +The macOS job that measured the iOS rows was written as a probe. Every step |
| 738 | +continued on error, because its first version stopped at the first unmet |
| 739 | +premise and skipped the four measurements after it, and for a probe that was |
| 740 | +correct. It stayed that way after those measurements moved `aarch64-ios-sim` to |
| 741 | +`verified`, and a probe is not a gate: a regression in the Apple cross path |
| 742 | +would have printed `RUN-THROUGH-RUNNER-FAILED` inside a job reported green, and |
| 743 | +the tier would have gone on claiming a run that no longer happened. |
| 744 | + |
| 745 | +The final review found it by reading the workflow rather than its result, which |
| 746 | +is the only way it could have been found. Every reading of that job was green. |
| 747 | + |
| 748 | +The job is now split along that distinction. `ios-host-surface` keeps the |
| 749 | +premise measurements, continues on error, and runs only on request, because a |
| 750 | +check that cannot fail, shown beside a gate, reads as a second gate. |
| 751 | +`ios-engine` fails on four claims. Each of the three artefacts must be a Mach-O |
| 752 | +of the row's architecture whose `LC_BUILD_VERSION` names the row's platform |
| 753 | +(`2` for the device, `7` for both simulator rows) and the project's `minos`, |
| 754 | +compared as whole values so that an empty reading fails. And |
| 755 | +`mcpp run --target aarch64-ios-sim` must exit 0 with `1-2-3` as a whole line of |
| 756 | +its output. |
| 757 | + |
| 758 | +The same review removed the fixture's three `toolchain = "llvm@22.1.8"` |
| 759 | +overrides. They were needed while the rows were `planned`, and they meant the |
| 760 | +job measured an override and never the rows' own pin, which is the path a |
| 761 | +project that declares nothing takes. |
| 762 | + |
| 763 | +Two smaller findings from the same pass have the shapes already recorded |
| 764 | +above. The located SDK path reaches three command lines and was quoted on two: |
| 765 | +the std module's own command spliced it into a shell string unquoted, while |
| 766 | +every other path in that string goes through `shq`, so an Xcode installed as |
| 767 | +`Xcode 16.app` would have broken only the module precompile. And the payload |
| 768 | +root joined `bin/` in the runner's search with a measurement behind it and no |
| 769 | +test. The rule is now `runner_lookup::payload_search_dirs`, and a unit test |
| 770 | +fails when it is reverted to `bin/` alone, which was checked by reverting it. |
| 771 | + |
732 | 772 | ## Gaps this batch recorded and did not close |
733 | 773 |
|
734 | 774 | Each is an engine or package change with a measurement behind it, and each was |
|
0 commit comments