mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
6e459a3860
This PR fixes two issues. Accidental reuse of code assets between build modes and SDKs (https://github.com/flutter/flutter/issues/181724), and the bundling in ios-frameworks (https://github.com/flutter/flutter/issues/181382). To fix the accidental caching, the `Target`s related to build hooks and code assets now output their files to `environment.outputDir` instead of `$projectDir/$buildDir/native_assets`. * `xcode_backend` is updated to deal with this. * `Flutter.kt` has been updated to deal with this. * Because the `Target`s are responsible for caching, the code has been refactored to provide the target directories from there. The "global-ish" function `nativeAssetsBuildUri` that was calculating the directory before has been removed. * `runFlutterSpecificHooks` has nothing to do with that directory, it's access to it has been removed. * To avoid another cmakefile migration, the Linux and Windows implementation use the same directory. (Note that output dir and build dir overlap for Linux and Windows, while they do not for MacOS, iOS, and Android.) * This also means that we don't have to read `NativeAssetsManifest.json` in `xcode_backend` anymore. Instead the `Target` clears the output directory, so we should not have any stale frameworks. * Refactored `installCodeAssets` and its platform-specific implementations to return a list of all produced files. These are now added to the `Target`'s depfile. This fixes an issue where the build system would skip re-installing native assets after an Xcode "Clean Build Folder because it wasn't tracking the frameworks/dylibs as outputs. Closes: https://github.com/flutter/flutter/issues/181724 Other `Target`s related tweaks: * Added proper `Source.pattern('{BUILD_DIR}/${DartBuild.dartHookResultFilename}'),` for all `Target`s that depend on that file. These were missing. (The build system uses `dependencies` for ordering of `Target`s, but relies on `inputs` and `outputs` for caching.) * Removed code assets from `CopyAssets`. That target is supposed to make an asset-bundle that is OS-independent if I understand correctly. This PR changes the way code assets are bundled in `flutter build ios-framework`. * This PR now packages in an `.xcframework`, which is necessary to be able to package both device and simulator. * Run through the frameworks of both device and simulator and give errors on inconsistencies. Closes: https://github.com/flutter/flutter/issues/181382 Other iOS related tweaks: * Use `xcrun` for invoking all the commands. (This is used for producing the app framework, but was not for code assets frameworks.) * Make sure all commands are added to the traces when running verbose. (Also to bring it in line for with the other `xcrun` commands.) Testing: * The integration test is updated to inspect the `xcframework`s. * Added a test that simulates Xcode "Product > Clean Build Folder...", to check that it now correctly triggers a rebuild. * We do _not_ have an integration test that _runs_ the frameworks output from `flutter build ios-framework` inside a host app at all as far as I'm aware. * dev/devicelab/bin/tasks/build_ios_framework_module_test.dart builds a framework, but doesn't run it in a host app * dev/integration_tests/ios_add2app_life_cycle/build_and_test.sh runs, but does so via `flutter build ios` not as a framework. * Does not add an integration test for caching behavior between switching build modes. However, the proper functioning of `flutter build ios-framework` depends on the `Target`s for different not using overlapping directories. Architectural approaches tried but didn't work: * Subclass `InstallCodeAssets` per OS to be more precise in the `output`s on what files are output. This doesn't work because other OS-independent targets on the `InstallCodeAssets` target.