SwiftPM re-reads every manifest when the environment changes, and
both it and Xcode key link and plugin tasks on PATH. An agent's shell
has a different PATH than the terminal's, so a build that was a no-op
in one relinks everything and regenerates the GTK bindings in the
other.
Run swift and xcodebuild from an allowlisted environment, with PATH
reduced to the directories that exist, each named once.
Same slim build as the Windows one, published to the same qemu-<build>
release as qemu-<build>-macos-arm64.zip -- arm64 only, which is what
the runners are. The binaries link Homebrew dylibs, so the closure is
copied into lib/, every load command rewritten to
@executable_path-relative names, and the touched Mach-Os re-signed
ad hoc. iOS is left out: nothing spawns subprocesses there.
Add a machine abstraction to LumaCore, with QEMU as its first
backend: templates mirroring frida-core's test guests, a QMP client,
and a display that maps QEMU's surface over D-Bus rather than
copying frames.
Leave readiness to the user: drive the guest, mark it ready, and come
back to that snapshot later. Keep the machine in the project, so
booting it again resumes where it was marked. Hand the stub to
addBareboneDevice, so it joins the picker beside the other devices.
Show the display while booting, and afterwards in a Machines panel,
which the side panel now models as an enum to share its slot.
Xcode enumerates a package target's resources when it loads the
package graph, before any build phase runs. An image staged from a
script phase is missing from that build's LumaCore, and the playground
crashes on the unwrap in boot().
Move the staging into scripts/stage-pharo-image.sh, called from
generate-sources.sh and both Makefiles.
Xcode enumerates a package target's sources when it loads the package
graph, before any build phase or scheme pre-action runs, so generated
Swift that appears during a build is missing from that build.
Move generation into scripts/generate-sources.sh, run it from the
Makefile, CI and the Luma scheme's pre-action, and drop the
AgentBundle target. Say what to run when the files are not there yet.
The playground, the notebook cells, the source editor with its
marks, the inspector columns and the canvas are written once for
both Apple platforms, with a file naming what the two frameworks
call differently. The editor is where they really part company.
The engine owns the image and its start-up, so a mission reaches
the whole of Pharo.
glslang and SPIRV-Cross build under neither SwiftPM nor Xcode, so
CI makes them into an xcframework and publishes it against a tag.
The manifest names that artifact; a build downloads it and needs
nothing local.
Ole André Vadla Ravnås