Martin Kustermann 01590aa27a Refactor native asset integration into flutter tools (#158932) ... Currently the `NativeAsset` target in flutter tools is responsible for two things: * performing the dart build (in the app as well as all transitive pub dependencies) * taking output (shared libraries) from this build and copying them around This intermingling of responsibilities leads to more complex code and potentially unnecessary work: If the source code changed (e.g. `.c` files change) we have to run the dart build again. But doing so may result in the same shared libraries (e.g. adding comments to the `.c` code). Currently we're going to copy the shared libraries despite them having not changed, which then may cause upstream things to be dirtied (if it's based on timestamp of files) and re-built. Instead this PR splits this `NativeAsset` into the two orthogonal pieces * `DartBuild` target that is responsible for the dart build * `InstallCodeAssets` that is responsible for copying shared libraries to the right place and producing a `native_assets.yaml`. This decoupling is also preparation for a future where a dart build can produce other kinds of assets (e.g. data assets) and is used in the web build as well. (The web build would use `DartBuild` but not `InstalCodeAssets`).		2024-11-15 21:04:42 +01:00
..
native_assets_test.dart	Refactor native asset integration into flutter tools (#158932)	2024-11-15 21:04:42 +01:00