-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Move embedding and linking macOS Flutter frameworks into the tool #71764
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
Conversation
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.
This logic is unchanged other than putting it in a function (so whitespace indentation) and adding locals.
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.
This is new.
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.
Also new.
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.
This file is almost the same as https://github.com/flutter/flutter/blob/e1598c96c072a6323e8dbf2a1724a896533a6c27/packages/flutter_tools/lib/src/ios/migrations/remove_framework_link_and_embedding_migration.dart with different identifiers, doesn't do anything with add-to-app, and leaves off any Xcode version checks.
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'll write a doc like https://flutter.dev/docs/development/ios-project-migration and link it here in a future PR.
e0c4519 to
0c3af8f
Compare
stuartmorgan-g
left a comment
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.
LGTM with nit. The Dart rework part is optional; if you go that route I can re-review that piece.
Thanks for tackling this; it's great to reduce delta relative to iOS, and this sets us up for some great improvements!
dev/benchmarks/macrobenchmarks/macos/Runner.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
dev/integration_tests/flutter_gallery/macos/Runner.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
dev/integration_tests/ui/macos/Runner.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
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.
This is non-trivial new bash code; any chance we could use this as the impetus to finally switch macOS over to tool_backend.* so that this could all be Dart code instead?
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 converging macOS and iOS scripts, and I'd like to do https://github.com/flutter/flutter/pull/70224/files#diff-cf570f69a008f028e95cfad7690ee32b3acbbc88379d340ea08ef67c0a3aff69R297 for macOS next (copy the FlutterMacOS framework directly to BUILT_PRODUCTS_DIR instead of ephemeral).
I'd rather get them to be the same bash script first since I know the iOS variant works, then swap them both over to the same dart code. That way each PR is a good improvement that isn't doing too much and is easy to review, and if it causes issues won't be a big painful revert.
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.
Actually, a macOS version of #59044 needs to happen first because the BUILT_PRODUCTS_DIR update requires a Podfile change, but you get the idea.
...tter_tools/lib/src/macos/migrations/remove_macos_framework_link_and_embedding_migration.dart
Outdated
Show resolved
Hide resolved
packages/flutter_tools/templates/app/macos.tmpl/Runner.xcodeproj/project.pbxproj.tmpl
Outdated
Show resolved
Hide resolved
packages/integration_test/example/macos/Runner.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
0c3af8f to
7238631
Compare
|
Google testing failing because #71757 hasn't rolled yet. |
Description
macOS version of #51453. See details and discussion there.
Push linker and embedding logic into the tool so future changes (like distributing as an XCFramework, renaming FlutterMacOS.framework, etc) do not require changes in the user's project.
At some point FlutterMacOS.framework will ship with x86 and ARM slices. With this change, we will be able to introduce thinning (as iOS does) in the script without requiring a user project migration.
This change would also set us up to stop copying
FlutterMacOS.frameworktoFlutter/ephemeral. On iOS, for example, the framework is copied directly from the artifacts directory to theBUILT_PRODUCTS_DIRso there's never a mismatch between a Release build and a Debug version of Flutter.Changes
disable_input_output_pathsfrom the generated Podfile, and from the example projects. Now that FlutterMacOS.framework isn't being technically emitted by a build phase, the Disable CocoaPods input and output paths in Xcode build phase and adopt new Xcode build system #33684 workaround is no longer necessary.Future Documentation
disable_input_output_pathscan be deleted. We decided not to automatically migrate this for existing iOS projects.Related Issues
Fixes #56581
Part of #70413
Will make #60113 easier.
Tests
macos_project_migration_test