-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Move Flutter.framework to build directory instead of ios/Flutter #70224
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
dd75ed5 to
f0732b9
Compare
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.
CocoaPods removed this since it's no longer embedding and code signing the Flutter.framework.
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 :debug and :release build configuration mapping is pulled from the Podfile, so flavor build configurations will be handled instead of trying to parse Flavor-Release==ios-release etc:
| project 'Runner', { | |
| 'Debug' => :debug, | |
| 'Profile' => :release, | |
| 'Release' => :release, |
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 the tricksy bit. CocoaPods is satisfied because Flutter.podspec exists, but it doesn't actually add the Flutter.framework or any embedding logic because the framework doesn't exist at this path.
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.
It's okay to use the BUILT_PRODUCTS_DIR engine for add-to-app because assemble put it in the right place.
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.
CocoaPods removed this since it's no longer embedding and code signing the Flutter.framework.
jonahwilliams
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
Do you have any other concerns about the fake podspec file? Is there a more difficult but more correct option that should be tracked?
The only thing I can think of is to remove the Another concern would be if CocoaPods changes its validation behavior to fail at |
|
This pull request is not suitable for automatic merging in its current state.
|
|
@jonahwilliams Nice test, you got me. |
f0732b9 to
d442b2d
Compare
Description
UnpackIOSbuild system target similar toUnpackMacOSso assemble will copy the Flutter.framework from the engine artifacts to the built products directory. For example,flutter build ios -v --simulatorwill copy to/build/ios/Debug-iphonesimulator/Flutter.framework.ios/Flutter/Flutter.framework. Remove it withflutter clean.FRAMEWORK_SEARCH_PATHSbuild setting from template and all example projects to prefer the built products directory, which we always get for free. I didn't write a migrator since leaving this around in existing apps is harmless--theinheritedpart means it will find our copied framework first.s.dependency 'Flutter'and CocoaPods will try to download it from the CoocaPods trunk if the Podfile doesn'tpod 'Flutter', :path => relative/filepodhelper.rb. Plugins will now link on the frameworks in the artifact cache (this is an absolute path added to the Pods project, but it's already excluded from source control in the.gitignoreso this should be fine)..ios/Flutter/enginedirectory. It will embed the assembly copied framework in the built products directory. I think this can be fixed, but it can be done in another PR.This will have the added benefit of speeding up build times since the framework will only be copied to the built products directory if assemble decides it's necessary.
Related Issues
Fixes #12631
Fixes #29840
Fixes #37850
Fixes #51989
Fixes #55013
First step of #60109
#60118
Similar to the work done to move App.framework to the built products directory #69699
Avoids #39356 (comment) (it would be possible to turn bitcode on if all plugins support bitcode)
App deltas may become easier to implement because the framework won't be re-copied (still more work needed to not re-codesign if it's already signed?) #67580
Tests
Checklist
///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change