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.

native/pkgs/native_assets_cli/lib/src/model/build_output.dart

Lines 19 to 25 in 22f4481

	class BuildOutput {
	/// Time the build this output belongs to started.
	///
	/// Rounded down to whole seconds, because [File.lastModified] is rounded
	/// to whole seconds and caching logic compares these timestamps.
	final DateTime timestamp;
	final List<Asset> assets;

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 Support standalone target without requiring Flutter SDK #645
• DataAsset: [native_assets_cli] data assets #154

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

native/pkgs/native_assets_cli/lib/src/model/build_config.dart

Line 20 in 22f4481

class BuildConfig {

Similar to #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:

• [ffi/js-interop/wasm] Unified API for using dart:ffi and JS Interop with WASM sdk#46690

[fzyzcjy]

This looks super useful, looking forward to it!

[MichealReed]

Continued here

I believe @mosuem's issue would be solved by flutter/flutter#164094 (comment), 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.