-
Notifications
You must be signed in to change notification settings - Fork 52
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Allow custom asset types in the build system (#1623)
This is the first PR that will increase the flexibility of the Dart
Build system as well as makes it more layered. The main points being
addressed in this PR are:
* A bundling tool has to specify which asset types it supports. So we
make `supportedAssetTypes` required everywhere.
=> Across various layers in the code base we make this required
=> We remove a baked-in `[CodeAsset.type]` fallback in various places
(Making this explicit increases size of LOCs in this CL due to the
many tests)
* The core building infrastructure in `pkg/native_assets_builder/lib/*`
no longer knows anything about `CodeAsset` or `DataAsset`. Instead it
only knows about `EncodedAsset` which represents the type of an asset
and it's json encoding.
=> The core still verifies certain protocol consistency (e.g. that a
hook only emitted asset types that the config allows)
=> The higher levels pass the `supportedAssetTypes`.
=> The higher levels now also pass `buildValidator` / `linkValidator`
that validate per-asset related things (e.g. the id of a data asset to
start with the package name) for a given package.
=> The higher levels now also pass a `applicationAssetValidator` that
validates consistency of assets across all packages (e.g. uniqueness
of dylib filenames across all dependencies)
=> This centralizes the logic about per-asset-type information in the
bundling tool (i.e. user of `package:native_assets_builder`).
=> Bundling tools now have to expand `CodeAsset`s in dry-run to all
architectures.
* The bundling tool (e.g. `flutter build`) doesn't have to implement
validation logic itself, instead it will support certain asset types
by importing the "bundling logic" for that asset types (which includes
- for now - validation logic).
* All the validation code now simply returns `ValidationError` which is
a list of errors. If the list is empty then there were no errors.
=> This removes redundancy between a `success` boolean and the list of errors
(it was successsfull iff there were no errors)
=> This simplifies code that aggregates errors from different sources.
* Moves the `fromJson` / `toJson` towards be purely read/write a json schema
and are not responsible for anything else.
=> The validation routines are responsible for validating semantics.
* The hook writer API now changes to work on per-asset-type specific
extension methods.
For example what used to be
```
output.addAsset(DataAsset(...));
```
is now
```
output.dataAssets.add(DataAsset(...));
```
The `BuildOutput.encodedAsset` getter is (with this PR) temporarily visible
to hook writers, which could use it like this:
```
output.encodedAssets.add(DataAsset(...).encode());
```
but a following refactoring that increases the flexibility of the
protocol more will also get rid of the user-visible `encodedAsset`
getter (if we choose so). So this is only temporarily exposed.
* `hook/link.dart` scripts have to mark any input files it's output
depends on in the `LinkOutput.addDependency`. If the set of inputs is
the same but one input's file changed then a `hook/link.dart`
- doesn't have to rerun if it just drops all assets or outputs them
unchanged
- has to re-run if it copies a input, changes it's contents, merge
with other inputs, etc
=> A `hook/link.dart` should - just like a `hook/build.dart` add
dependencies if the inputs are used to produce the output
=> Before this was somewhat hard-coded into the
`package:native_assets_builder`.- Loading branch information
1 parent
0bf27dc
commit d8a84ea
Showing
116 changed files
with
1,473 additions
and
1,035 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.