Cross compiling to Intel macOS seems fine, but it would be good to cross compile to arm64-apple-darwin as well.
Further reading:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33549.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | Sjors, hodlinator |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
The title is a bit confusing: “Use ARM instead of Intel in macOS cross task”
Maybe say “Build for” instead of “use”, since the job uses Ubuntu to build.
It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we’ll get from Github.
It might be better to test cross compilation for both x86 and arm, though if that takes too much CI resources then arm is probably the more important target.
Briefly running the cross-compiled x86 binary on a native x86 CI machine would be useful, but it looks like Rosetta is the best we’ll get from Github.
Happy to add this to my nightly CI repo, but it doesn’t seem like a good use of CI resources here. Though, best I can do is the Rosetta 2 from GitHub.
but it doesn’t seem like a good use of CI resources here.
Having at least compilation coverage of every target we are shipping a release binary for seems like something we should have? Post switchover we are much less constrained on the CI resources front.
This refactor does not change behavior, but allows the step to be
re-used in other tasks, such as a mac-test-cross task
Having at least compilation coverage of every target we are shipping a release binary for seems like something we should have? Post switchover we are much less constrained on the CI resources front.
Thx, done. Also, agree that cross-compilation is cheap and fast.
utACK fad5a7101cc3dccbb525cfe9afc105aace8da88e
CI log suggests it worked.
nits in fa8c750a0aff9c03270b71a91536639f3922eed8: Can’t see any reference in the configs/scripts for how this step is reused for Mac. Maybe there’s some part of the Cirrus config I’m not finding, although I can’t see it being run in the logs either (https://productionresultssa9.blob.core.windows.net/actions-results/b7d9a1c2-e433-4d61-91b6-663cde22c2f6/workflow-job-run-8d60d8fe-2ef0-566b-bad9-1d540924800c/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-10-14T09%3A00%3A24Z&sig=F60Lcc0LkB2xmwQ8QEIREe5JYNIARFMwHunBtS%2FVfGw%3D&ske=2025-10-14T19%3A50%3A15Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-10-14T07%3A50%3A15Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2025-10-14T08%3A50%3A19Z&sv=2025-11-05). Good simplification though.
Seems more precise with:
0- mac-test-cross
1+ macOS-cross
reviewed: Diffed against ci/test/00_setup_env_mac_cross.sh and only CONTAINER_NAME & HOST differ by CPU-arch, as expected.
Makes sense to have ARM be the main one going forward and move the old setup to “_intel”.