[macOS] Enable universal binary builds by default #100271
Merged
Conversation
This file contains 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
flutter-dashboard
bot
added
the
tool
cbracken
force-pushed
the
tool-apple-silicon
branch
from
f037f90
to
d8f66fc
Compare
This changes the default build architectures for Flutter macOS apps to x86_64 and arm64. Previously, we manually excluded arm64 builds via the EXCLUDE_ARCHS Xcode setting in Flutter's generated xcconfig file. This eliminates setting EXCLUDE_ARCHS during the build and updates the default architectures in the tool and in the macos_assemble.sh wrapper. Issue: flutter#97681 Umbrella issue: flutter#60113
cbracken
force-pushed
the
tool-apple-silicon
branch
from
d8f66fc
to
0ab2211
Compare
cbracken
added
platform-mac
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/packages
that referenced
this pull request
Mar 17, 2022
10 tasks
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/plugins
that referenced
this pull request
Mar 18, 2022
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/plugins
that referenced
this pull request
Mar 18, 2022
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/plugins
that referenced
this pull request
Mar 18, 2022
8 tasks
cbracken
added a commit
to cbracken/flutter
that referenced
this pull request
Mar 22, 2022
Previously, flutter#100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: flutter#100348
cbracken
added a commit
that referenced
this pull request
Mar 22, 2022
Previously, #100271 enabled building universal macOS binaries by default, but included a bug causing the arm64 App.framework to be built such that the TEXT section containing the app instructions built by gen_snapshot incorrectly contained x86_64 instructions rather than arm64 instructions. When building macOS (and iOS) apps, Flutter builds them in three components: * The Runner application: built by Xcode * The bundled App.framework: built from assembly code generated by gen_snapshot from the application's Dart sources. * The bundled FlutterMacOS.framework: built as part of the engine build and packaged by copying the distributed binary framework from our artifacts cache. Building App.framework consists of the following steps: * For each architecture, invoke gen_snapshot to generate architecture-specific assembly code, which is then built to object code and linked into an architecture-specific App.framework. * Use the `lipo` tool to generate a universal binary that includes both x86_64 and arm64 architectures. Previously, we were building architecture specific App.framework binaries. However, for all architectures we were (mistakenly) invoking the general `gen_snapshot` tool (which emitted x64 instructions, and which is now deprecated) instead of the architecture-specific `gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit instructions for the correct architecture. This change introduces a small refactoring, which is to split the `getNameForDarwinArch` function into two functions: * `getDartNameForDarwinArch`: the name for the specified architecture as used in the Dart SDK, for example as the suffix of `gen_snapshot`. * `getNameForDarwinArch`: the name for the specified architecture as used in Apple tools, for example as an argument to `lipo`. For consistency, and to match developer expectations on Darwin platforms, this is also the name used in Flutter's build outputs. Issue: #100348
8 tasks
gaaclarke
pushed a commit
that referenced
this pull request
Oct 20, 2023
Make the `NativeAssets` target consistent with `build_info.dart`'s documentation on missing `IosArchs` or `DarwinArchs`. Bug: * #136931 Also, updates the doc to reflect that MacOS is by default built for both x64 and arm64. The PR making universal binaries the default didn't update the doc comment. * #100271 Please note that these defines are handled inconsistently in `flutter_tools`. In some places they default to what's specified in the doc-comment. In other places a `MissingDefineException` is thrown. I believe the code around `build_info.dart` and the `environment` could benefit from a wrapping so that defaults or missing definitions are handled consistently in the code base. ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [ ] I added new tests to check the change I am making, or this PR is [test-exempt]. - [ ] All existing and new tests are passing. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/wiki/Tree-hygiene#overview [Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene [test-exempt]: https://github.com/flutter/flutter/wiki/Tree-hygiene#tests [Flutter Style Guide]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo [Features we expect every widget to implement]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/wiki/Chat
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This changes the default build architectures for Flutter macOS apps to
x86_64 and arm64. Previously, we manually excluded arm64 builds via the
EXCLUDE_ARCHS Xcode setting in Flutter's generated xcconfig file. This
eliminates setting EXCLUDE_ARCHS during the build and updates the
default architectures in the tool and in the macos_assemble.sh wrapper.
Issue: #97681
Umbrella issue: #60113
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.