Compilation of native code to WASM

[dcharkes]

We should consider supporting compiling C code in build.dart to WASM and teaching dart2wasm & dart2js how to bundle/link the compiled libraries.

This feature likely needs to be owned by the dart2wasm team for dart2wasm integration. cc @eyebrowsoffire I believe @eyebrowsoffire also had some ideas about dart2js interop with WASM.

This issue is to track what the CLI API should look like for this integration.

Currently the BuildOutput is tied to dynamic/static libraries that need to specify on what OS/Architecture they run.

https://github.com/dart-lang/native/blob/22f4481573c201542daa1451fc3c58b1e50bf75a/pkgs/native_assets_cli/lib/src/model/build_output.dart#L19-L25

We could relax the properties of Asset, but it might be better to start distinguishing different types of assets.

• NativeCodeAsset: The current asset.
• WasmCodeAsset: Compiled WASM (non-GC) code asset. With whatever properties these assets need.
• JavaCodeAsset: to address https://github.com/dart-lang/native/issues/645
• DataAsset: https://github.com/dart-lang/native/issues/154

The BuildConfig also needs some modification to signal to to the build.dart script we're targeting the web.

https://github.com/dart-lang/native/blob/22f4481573c201542daa1451fc3c58b1e50bf75a/pkgs/native_assets_cli/lib/src/model/build_config.dart#L20

Similar to https://github.com/dart-lang/native/issues/154, this also triggers the question of package:native_assets_cli. We could try to only loosely couple the API by only providing the JSON/YAML format instead of a parser, but that just means build.dart script writers will need to write their own parser. So it's probably better to try to cover all types of assets in one protocol. So then the package should be renamed package:build_scripts or something.

Also, build.dart is currently not run in dart2wasm and dart2js. So that will need to be addressed as well.

Related issue:

• https://github.com/dart-lang/sdk/issues/46690

[fzyzcjy]

This looks super useful, looking forward to it!

[MichealReed]

Continued here

I believe @mosuem's issue would be solved by https://github.com/flutter/flutter/pull/164094#discussion_r2003507508, please let me know if it doesnt.

Yes, this allows use of the asset. The concept behind #2108 would provide a way in the hook to compile for web (for example, use emcmake vs cmake command), which the mentioned flutter PR does not cover.

I think it makes sense to see web as a separate target outside of js and wasm. WASM and JS can be used on the web, but does not always target the web. With a web target, js and wasm could be included via a produced html template, since web can only be used with html. The template could also include nested libraries the same way, making all the calls available to any framework that includes the generated template.