New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDART-962: Use xcode 15.3 #1548
base: main
Are you sure you want to change the base?
Conversation
Pull Request Test Coverage Report for Build 8818661315Details
💛 - Coveralls |
19be2b2
to
17827e8
Compare
0fe31e9
to
3d02b62
Compare
@@ -3,18 +3,10 @@ name: Dart desktop tests | |||
on: | |||
workflow_call: | |||
inputs: | |||
os: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I'm a huge fan of the changes in this file. I understand that it removes some redundant pieces of information, but it complicates the setup somewhat and forces readers to familiarize themselves with the architectures of the various github-hosted runners.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous code had assumptions about the architecture, that didn't actually match the runners, implicitly assuming arch was x86_64
unless architecture
was set to arm
. That is not correct for macos-14, which is being rolled out as macos-latest
as of yesterday (github/roadmap#926).
One thing I regret is that I cannot show the arch in the job title, as we don't know what runner is being used yet, so it is only shown in the steps. And obviously I would have preferred for github action expressions to be expressive enough to lowercase a simple string 🙄
What if I reintroduce the architecture
argument, and make a step that explicitly test that it actually match runner.arch
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'd be fine with that.
submodules: 'recursive' | ||
submodules: "recursive" | ||
|
||
- name: Select XCode for MacOS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to increase the ulimit here it seems.
@@ -7,4 +7,4 @@ set -o pipefail | |||
cd "$(dirname "$0")/.." | |||
|
|||
cmake --preset macos | |||
cmake --build --preset macos --config MinSizeRel -- -destination "generic/platform=macOS" | |||
cmake --build --preset macos --config Release -- -destination "generic/platform=macOS" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MinSizeRel
becomes -Os
which apparently clang++
(from XCode 15.x) don't like, hence this change.
@@ -168,7 +168,7 @@ | |||
"configurePreset": "macos", | |||
"nativeToolOptions": [ | |||
"-destination", | |||
"platform=macOS" | |||
"generic/platform=macOS" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of XCode 15.3 it is apparently important to use generic/platform=macOS
during preset, to actually end up with a universal binary (ie. supporting both arm64
and x86_64
).
The downside of this change is that we also build for x86_64
on our dev machines, but given that we use ccache
it is perhaps a non-issue in practice.
1da63ba
to
f69615f
Compare
Update CHANGELOG Use Release instead of MinSIzeRel
Fixes: #1547
Use macos-14 runner for arm64 and macos-13 runner for x86_64.
Use xcode 15.3 which changes a bit how to build universal binaries.