{{ message }}
fix(mac): build-local.sh works on modern SDKs and copies the resource bundle - #1262
Draft
sm0keyyy wants to merge 1 commit into
Draft
fix(mac): build-local.sh works on modern SDKs and copies the resource bundle#1262sm0keyyy wants to merge 1 commit into
sm0keyyy wants to merge 1 commit into
Conversation
… bundle The script copied the product binary and icons into the bundle but never the SwiftPM resource bundle, so every app it assembled died at startup with 'unable to find bundle named CodeBurnMenubar_CodeBurnMenubar'. It also exited 1 before compiling on any SDK newer than 14.x, and required a swift.org toolchain that is unnecessary when Xcode or the Command Line Tools provide swift. Selection is now capability-driven, preferring Xcode's SDK because libSwiftUIMacros.dylib, which expands SwiftUI's @State macro on macOS 15+ SDKs, ships only inside Xcode. Gates the @mainactor rewrite to the 14.x SDK it was written for, and drops the redundant per-arch builds plus lipo merge in favour of one two-arch build.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
mac/Scripts/build-local.shcannot produce a working app on a current macOS toolchain. This pull request corrects 2 defects. Neither is specific to any package manager or host configuration: the first breaks every app the script assembles, and the second stops the script before it compiles anything.1. The assembled app could not launch, because the resource bundle was never copied
The script copies the product binary and the generated icons into the bundle, but not the SwiftPM resource bundle. Any app it assembled terminated during startup:
Bundle.moduleresolves that bundle from the app'sContents/Resources. SwiftPM emits it as a sibling of the executable in the build products directory, so it has to be copied in alongside the binary. The script now copies every*.bundlefrom that directory.This became reachable when target resources entered
Package.swift; the script was never updated to match. It is independent of defect 2 and of any host specifics.2. The script exited before compiling on any SDK newer than 14.x
Two hard exits made the script unusable on a current toolchain:
~/Library/Developer/Toolchains/and exited 1 when none was present, even though theswiftprovided by Xcode or the Command Line Tools is sufficient.14.xand exited 1 otherwise.Selection is now capability-driven rather than pinned. The compiler is a swift.org toolchain when one is installed, otherwise
swiftfromPATH. The SDK is Xcode's when/Applications/Xcode.appis present, otherwise whateverxcrunreports. When the SDK is newer than 14.x and Xcode is absent, the script fails with an actionable message instead of a version mismatch.Preferring Xcode's SDK is not cosmetic. On macOS 15+ SDKs SwiftUI's
@Stateis a macro, and the plugin that expands it,libSwiftUIMacros.dylib, ships only inside Xcode. Command Line Tools 27.0 carries onlylibObservationMacros.dylibandlibSwiftMacros.dylib, so compiling any view against the CLT SDK fails:An SDK and its macro plugins must be used as a matched pair. Supplying Xcode 26.6's plugin to the CLT 27.0 SDK expands
@Stateinto a member that SDK does not declare:Selecting Xcode's own SDK avoids this entirely: there
@Stateis an ordinary property wrapper and no macro plugin participates in the build.Two consequences follow. The
@MainActorsource rewriting is now gated to the14.xSDK it was written for, because later SDKs already carry those annotations; the14.*branch keeps the originalperlrewrite verbatim. And the two-arch build is a single invocation, which routes through xcbuild and emits a fat binary directly, so the separate per-arch builds and thelipomerge that followed them are redundant.Change evidence
*.bundlefrom the products directory intoContents/Resourcesresource_bundle_accessor.swift:44: Fatal error: unable to find bundle named CodeBurnMenubar_CodeBurnMenubar, process exit code -5, no child process spawned. After the change,Contents/ResourceslistsAppIcon.icns,CodeBurnMenubar_CodeBurnMenubar.bundle,menubar-logo.png, and the same launch stays alive and spawns itscodeburn serve --stdiochild, confirmed bypgrep -P <app pid>reporting a matching ppid.mac/Scripts/build-local.sh dev-nixfixend to end: rc 0 in 41 s. Output recordsToolchain : Apple Swift version 6.4 (swiftlang-6.4.0.33.1 clang-2100.3.33.1)andSDK : /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk (26.5), then✓ Installed. Before the change the same invocation exited 1 at the toolchain probe on this host, having compiled nothing.lipo -infoon the assembled binary reportsx86_64 arm64.vtool -show-buildreportsminos 14.0. Both match the script's prior contract.liposwift build -c release --arch arm64 --arch x86_64returned rc 0 in 38 s andlipo -infoon the product reportedx86_64 arm64, with nolipo -createstep involved.--show-bin-pathunder the same flags resolves to.build/out/Products/Release, which is also where the resource bundle is emitted, so one query locates both copy sources.@MainActorrewriting gated to the 14.x SDKSDK 26.5 already annotates SwiftUI, skipping @MainActor patchand still produced a launchable app, so the rewrite is not required on the newer SDK. The14.*branch retains the originalperlinvocation unchanged, so the legacy path is untouched.mac/, so the existing suite must stay green.npm test: 272 test files passed, 2 skipped; 3738 tests passed, 5 skipped, 0 failed; duration 34.30 s. Rannpm run build: rc 0, emittingdist/main.js(2.29 MB),dist/parse-worker.js(864.47 KB), and the dash bundle.Environment
Verified on macOS 27.0, Apple Silicon, with no swift.org toolchain installed.
xcode-select -p/Library/Developer/CommandLineToolscom.apple.pkg.CLTools_Executablesversion 27.0.0.0.1787197235libObservationMacros.dylib,libSwiftMacros.dylibonly; nolibSwiftUIMacros.dylibanywhere under CLT or its SDKlibSwiftUIMacros.dylib~/Library/Developer/ToolchainsNote that
xcode-selectstill points at the Command Line Tools in the verified run. The script selects Xcode's SDK explicitly, so a globalxcode-selectswitch is not required and neither issudo xcodebuild -license accept.Notes
The script's header comment is unchanged and still describes the Sonoma case it was written for; the
14.xpath behaves exactly as before.The
x86_64slice was cross-compiled and not executed; only thearm64slice was run.Companion pull request #1263 fixes a separate runtime defect in
CodeburnCLI.swift. The two do not overlap in files. This one is a prerequisite for building and verifying that change locally on a modern toolchain, so it should land first.Testing
npm testpassesnpm run buildsucceedsReal-data check: the app the fixed script assembles was installed to
~/Applications/CodeBurnMenubar.app, launched, and rendered a flame icon with a live dollar figure in the menu bar against the local corpus, with itscodeburn serve --stdiochild confirmed alive by ppid.Files (1)