build: keep the local daemon builds universal, matching CI - #655
Open
filip131311 wants to merge 1 commit into
Open
build: keep the local daemon builds universal, matching CI#655filip131311 wants to merge 1 commit into
filip131311 wants to merge 1 commit into
Conversation
`build.sh` is what `pack:mcp:local` uses, and the CI workflow that produces the published binaries states it mirrors this script. Its three daemon compiles built arm64 only, like CI's did, so a locally packed tarball had the same gap as a published one: a universal `simulator-server` next to an arm64-only `ax-service`. `-target` stays and `-arch` is added, rather than moving the platform onto a version-min flag — if the platform were carried only by that flag, losing it would silently produce a macOS binary that packs fine and only fails when spawned in a simulator. `tvos-hid-daemon` gets the deployment target it never had. Without it the floor is whatever Xcode built it, which on a current machine is macOS 26 — high enough to exclude the Intel hosts the second slice exists for. Verified by running this script: all three come out `x86_64 arm64`, the simulator binaries keep `IOSSIMULATOR 17.0` on both slices, and the daemon reports `MACOS 14.0` rather than the local toolchain's 26.0. Refs #639
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.
Companion to software-mansion/argent-private#29. Together they fix #639.
Split of work
The binaries users install are not built by this script — they come from
build-native-binaries.ymlinargent-private, which duplicates the compile commands inline. So theload-bearing fix is argent-private#29;
this PR keeps
build.sh(thepack:mcp:localpath) in step, which that workflow's own commentpromises it mirrors. Letting them drift is how the gap appeared.
The change
The three daemon compiles built arm64 only while the dylibs five lines away already cross-compile
both slices, so a locally packed tarball had a universal
simulator-servernext to an arm64-onlyax-service.-targetis kept and-arch arm64 -arch x86_64added — identical output, but theplatform stays pinned by something that fails loudly rather than by a flag whose loss would silently
yield a macOS binary that packs fine and only dies at
simctl spawn.tvos-hid-daemonalso gets-mmacosx-version-min=14.0. It was the only compile with no deploymenttarget, so its floor was whatever Xcode built it — on a current machine that is macOS 26, which would
exclude nearly every Intel Mac the x86_64 slice exists for. 14.0 is what the shipped binary already
reports, so this is a no-op against the current artifact.
Verification
Ran this script end to end against the real private sources:
Not verified: that the x86_64 slices run — no Intel Mac and no x86_64 simulator runtime here.
This restores a build pattern the repo already uses everywhere else; it is not a tested claim of Intel
support, and no doc is changed to say otherwise.
Note for whoever merges
Merging both PRs is still not enough for the fix to reach an npm release:
publish-npm.ymlpins afrozen
argent-<ref>binaries tag built by a manual dispatch of the private workflow. Afterargent-private#29 lands, that workflow needs a dispatch against the tag the next release will use.