add wasm32-wasi-preview2 target

[dicej]

Currently, this is identical to the wasm32-wasi in all but name. See #449 for the next step, which is to incrementally add Preview 2 features, e.g. wasi-sockets. Per the discussion in that PR, I've split the wasi-sysroot/include directory into per-target directories. Eventually, we'll want to build a separate sysroot for each target, but there's currently uncertainty about how to configure the default sysroot for e.g. clang, so we're not tackling that yet.

See also #447 for further details.

[sbc100]

Is the plan the binaries built with wasm32-wasi-preview2 can/will also contain preview1 imports? i.e. that they will be kind of a hybrid of the two?

[dicej]

Is the plan the binaries built with wasm32-wasi-preview2 can/will also contain preview1 imports? i.e. that they will be kind of a hybrid of the two?

Yes, initially. See the Proposal section of #447 for details. Eventually, we'll remove all preview1 imports, at which point the preview1->preview2 adapter will no longer be needed.

[sbc100]

Great.

Off-topic-followup: I'm curious how wit-component and the adapter work exactly. Is it possible for the end result to be a single core wasm with preview1 + preview2 imports? i.e. will we be able to run the results on engines that don't directly support the component model?

[dicej]

Off-topic-followup: I'm curious how wit-component and the adapter work exactly. Is it possible for the end result to be a single core wasm with preview1 + preview2 imports? i.e. will we be able to run the results on engines that don't directly support the component model?

Yes, you could use the module directly without any adapter or wit-component if you had a host that could satisfy both the preview1 and preview2 imports at the module level.

Also I believe @cpetig has experimented with building the adapter as a .a file and linking it using wasm-ld, which would give you a module that only imports preview2 functions (but is still a module, not a component).

[sbc100]

Yes, you could use the module directly without any adapter or wit-component if you had a host that could satisfy both the preview1 and preview2 imports at the module level.

Awesome!

(It sounds like we will be able to use emcc --post-link <module.wasm> with such modules and that emcc will be able to supply both preview1 and preview2 imports to allow such modules to run on the web).

[dicej]

(It sounds like we will be able to use emcc --post-link <module.wasm> with such modules and that emcc will be able to supply both preview1 and preview2 imports to allow such modules to run on the web).

Sounds great. Note that you can also use jco to run Preview 2 components on the web.

[dicej]

Any feedback on the PR itself? I was thinking I'd add the generated WIT bindings and Makefile support for regenerating them in a separate PR, but I could add them to this one if desired.

[sbc100]

Any feedback on the PR itself? I was thinking I'd add the generated WIT bindings and Makefile support for regenerating them in a separate PR, but I could add them to this one if desired.

I love small PRs so if you can separate them like this I'd appreciate it.

[sbc100]

lgtm but I've added @sunfishcode as a reviewer, since I don't know the wit-component + adapter stuff in the test directory works.

Also, want to make sure @sunfishcode is OK with the separate multi-arch include directory approach?

[sunfishcode]

Looks good to me. I expect the adapter logic there will evolve, but this looks like a good starting point.

The separate multi-arch include setup seems good to me.