[wasm] Integrate naot-llvm into workload manifest

[maraf]

trafficstars

TODO

• [ ] Add WBT test (both wasi and browser)
• [ ] Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• [x] Split the version property out to separate file to make it overridable by automation
• [ ] Don't re-enable browser workload from emscripten workload manifest
• [x] ~~Update Microsoft.NETCore.App (KnownFrameworkReference) version to correct version of JS interop generator or ship the generator other way~~ (fixed in naot branch)
• [ ] Prepare gh action to update the version
• [ ] Should we print some message/warning about experimental feature?

[dotnet-policy-service[bot]]

Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.

[maraf]

🎉

https://helix.dot.net/api/jobs/b6510edc-db92-4a49-a9c5-37b3bb3511ba/workitems/Workloads-ST-Wasi.Build.Tests.NativeAOTTests?api-version=2019-06-17

[am11]

Prepare gh action to update the version Should we once in a while check for newer version LLVM packages?

Maybe @dotnet/runtime-infrastructure might have ideas but sounds like it could use DARC subscription for runtimelab -> runtime package sync (like the regular code flow), instead of a standalone GH action?

[jkotas]

If you would like to promote the current runtimelab project to "shipping with dotnet/runtime", the proper way to do that is by integrating it to dotnet/runtime.

[maraf]

If you would like to promote the current runtimelab project to "shipping with dotnet/runtime", the proper way to do that is by integrating it to dotnet/runtime.

We don't want to promote the runtimelab project to shipping with dotnet. The goal is to make the integration easier. Primarily by enabling usage of our build of emscripten and remove the need for disabling workload resolvers, but since the deeper integration on wasm scope worked, I tried to go deeper. We have the wasm-experimental workload which seemed like a reasonable place to introduce such integration.

Anyway, if the current scope is too deep, I'm happy to reduce it to follow the original goals.

[jkotas]

It is fine to make small target changes in dotnet/runtime repo to support the projects that we run in runtimelab.

dotnet/runtime repo should not be taking dependencies on runtimelab artifacts or feeds. Referencing https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-experimental feed in dotnet/runtime is a red flag. runtimelab can reference dotnet/runtime feeds, but not the other way around.

[dotnet-policy-service[bot]]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[dotnet-policy-service[bot]]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.