mirror of
https://github.com/flutter/flutter.git
synced 2025-06-03 00:51:18 +00:00
ea208f824b
### Problem
Enabling the Swift Package Manager feature caused post-submit tests to fail on Mac x64 hosts:
<details>
<summary>Example error...</summary>
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20rrect_blur_perf_ios__timeline_summary/575/overview
```
⦠... flutter --verbose assemble ... -dIosArchs=x86_64 ... profile_unpack_ios
Target profile_unpack_ios failed:
Exception: Binary ... build/ios/Profile-iphoneos/Flutter.framework/Flutter does not contain x86_64.
Running lipo -info:
Non-fat file: ... build/ios/Profile-iphoneos/Flutter.framework/Flutter is architecture: arm64
#0 UnpackIOS._thinFramework (package:flutter_tools/src/build_system/targets/ios.dart:351:7)
<asynchronous suspension>
#1 UnpackIOS.build (package:flutter_tools/src/build_system/targets/ios.dart:298:5)
<asynchronous suspension>
...
```
</details>
### Reproduction
On a mac x64 host:
1. Switch to the latest master channel: `flutter channel master ; flutter upgrade`
1. Disable the Swift Package Manager feature: `flutter config --no-enable-swift-package-manager`
2. Create a Flutter project
2. [Edit the Xcode project manually to add the prepare pre-action](https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers#step-2-add-run-prepare-flutter-framework-script-pre-action)
3. Run `flutter run` (`flutter build ios` does not reproduce this issue).
### Background
Previously, the Flutter framework was unpacked in the Xcode target's build. Unfortunately, this happens after Swift packages are built; this prevented Swift packages from using the Flutter framework.
To fix this, we added an Xcode pre-action that unpacks the Flutter framework _before_ Swift Package Manager builds packages. The Xcode target still runs the Flutter framework unpack step, but this step no-ops if the unpack step has the exact same inputs.
```mermaid
flowchart LR
A[flutter run -d iphone] --> B(Build Xcode project)
B --> C(Xcode 'prepare framework' pre-action)
B --> G[Build Swift packages]
B --> D(Build 'Runner' target)
C --> E[Unpack Flutter framework #1]
D --> F["
Unpack Flutter framework #2
(No-ops if inputs are same as #1)
"]
```
https://github.com/flutter/flutter/pull/150052 added an optimization that made it more likely the second unpack step no-ops by fixing a case where the target architecture input could be different:
> When using SwiftPM, we use `flutter assemble` in an Xcode Pre-action to run the `debug_unpack_macos` (or profile/release) target. This target is also later used in a Run Script build phase. Depending on `ARCHS` build setting, the Flutter/FlutterMacOS binary is thinned. In the Run Script build phase, `ARCHS` is filtered to the active arch. However, in the Pre-action it doesn't always filter to the active arch. As a workaround, assume arm64 if the [`NATIVE_ARCH`](https://developer.apple.com/documentation/xcode/build-settings-reference/#NATIVEARCH) is arm, otherwise assume x86_64.
This optimization is only applied if [`ONLY_ACTIVE_ARCH`](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW157) is `YES`.
> [!IMPORTANT]
> [`ONLY_ACTIVE_ARCH`](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW157)'s name is misleading. It specifies whether the product includes only object code for the native architecture.
>
> A value of `YES` means the product includes only code for the native architecture ([NATIVE_ARCH](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW59)).
>
> A value of `NO` means the product includes code for the architectures specified in [ARCHS (Architectures)](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW62).
### Problem
`buildXcodeProject` incorrectly always sets `ONLY_ACTIVE_ARCH` to `YES` if the Xcode built is for a single architecture:
|
||
|---|---|---|
| .. | ||
| code_signing_test.dart | ||
| core_devices_test.dart | ||
| devices_test.dart | ||
| ios_deploy_test.dart | ||
| ios_device_install_test.dart | ||
| ios_device_logger_test.dart | ||
| ios_device_port_forwarder_test.dart | ||
| ios_device_project_test.dart | ||
| ios_device_start_nonprebuilt_test.dart | ||
| ios_device_start_prebuilt_test.dart | ||
| ios_project_migration_test.dart | ||
| ios_workflow_test.dart | ||
| mac_test.dart | ||
| simulators_test.dart | ||
| xcode_debug_test.dart | ||
| xcodeproj_test.dart | ||
| xcresult_test_data.dart | ||
| xcresult_test.dart | ||