Skip to content

Conversation

@jmagman
Copy link
Member

@jmagman jmagman commented Nov 10, 2020

Description

  • Create UnpackIOS build system target similar to UnpackMacOS so assemble will copy the Flutter.framework from the engine artifacts to the built products directory. For example, flutter build ios -v --simulator will copy to /build/ios/Debug-iphonesimulator/Flutter.framework.
  • Stop copying the Flutter.framework to ios/Flutter/Flutter.framework. Remove it with flutter clean.
  • Remove FRAMEWORK_SEARCH_PATHS build 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--the inherited part means it will find our copied framework first.
  • Move the Flutter search path and linking behavior out of CocoaPods by generating a "fake" Flutter.podspec that doesn't point to a real framework. This is necessary because plugin podspecs contain s.dependency 'Flutter' and CocoaPods will try to download it from the CoocaPods trunk if the Podfile doesn't pod 'Flutter', :path => relative/file
  • Search path and linking is now handled by adding build settings in the Podfile via the podhelper.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 .gitignore so this should be fine).
  • This doesn't change any add-to-app copying behavior--the framework is still being copied to the .ios/Flutter/engine directory. 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

  • Unpack copies Flutter.framework
  • plugin_lint_mac
  • clean test

Checklist

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I signed the [CLA].
  • I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I updated/added relevant documentation (doc comments with ///).
  • All existing and new tests are passing.
  • The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

  • No, no existing tests failed, so this is not a breaking change.
  • Yes, this is a breaking change. If not, delete the remainder of this section.

@jmagman jmagman added platform-ios iOS applications specifically t: xcode "xcodebuild" on iOS and general Xcode project management labels Nov 10, 2020
@jmagman jmagman self-assigned this Nov 10, 2020
@flutter-dashboard flutter-dashboard bot added d: examples Sample code and demos c: contributor-productivity Team-specific productivity, code health, technical debt. tool Affects the "flutter" command-line tool. See also t: labels. work in progress; do not review labels Nov 10, 2020
@google-cla google-cla bot added the cla: yes label Nov 10, 2020
@jmagman jmagman force-pushed the framework-build-system branch 2 times, most recently from dd75ed5 to f0732b9 Compare November 14, 2020 01:43
Copy link
Member Author

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.

Copy link
Member Author

@jmagman jmagman Nov 14, 2020

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,

Copy link
Member Author

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.

Copy link
Member Author

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.

@jmagman jmagman marked this pull request as ready for review November 14, 2020 02:10
Copy link
Member Author

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.

Copy link
Contributor

@jonahwilliams jonahwilliams left a 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?

@jmagman
Copy link
Member Author

jmagman commented Nov 16, 2020

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 s.dependency 'Flutter' from the plugin template the next time we increase the sdk version constraint (like #62605) past this change, though I think we would need to keep supporting this for older plugins.

Another concern would be if CocoaPods changes its validation behavior to fail at pod install if the vendored framework path doesn't exist. Right now it doesn't complain, creates the Flutter pod target, but doesn't add a framework and doesn't add the bogus path to the other pods's search path, which is exactly what we want.

@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • The status or check suite Mac build_tests has failed. Please fix the issues identified (or deflake) before re-applying this label.

@jmagman
Copy link
Member Author

jmagman commented Nov 16, 2020

@jonahwilliams Nice test, you got me.

Not all build targets cached after second run.
The target performance data was: 
...
{"name":"debug_unpack_ios","skipped":false,"succeeded":true,"elapsedMilliseconds":33},

@jmagman jmagman force-pushed the framework-build-system branch from f0732b9 to d442b2d Compare November 16, 2020 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c: contributor-productivity Team-specific productivity, code health, technical debt. d: examples Sample code and demos platform-ios iOS applications specifically t: xcode "xcodebuild" on iOS and general Xcode project management tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

4 participants