[wasm] Integrate naot-llvm into workload manifest

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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

[maraf]

TODO

• Don't re-enable browser workload from emscripten workload manifest
• Add WBT test
  • Setup NativeAOT-LLVM dependencies on Helix
    • Visual C++ Redistributable (not needed after removal of LLVMSharp dependency)
    • To use emscripten workload, we need the bump to 3.1.56
    • Untie emscripten workload from BrowserWorkloadEnabledAllow to use emscripten workload separately emsdk#869
  • Wasi
  • Browser
• Needs to drop ImportRuntimeIlcPackageTarget target override in naot-llvm
• Split the version property out to separate file to make it overridable by automation
• 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?
• Should we once in a while check for newer version LLVM packages?

---

An alternative approach as a result for this experimentation

<UsingBrowserRuntimeWorkload>false</UsingBrowserRuntimeWorkload>
<UsingWasiRuntimeWorkload>false</UsingWasiRuntimeWorkload>
<UsingEmscriptenWorkload>true</UsingEmscriptenWorkload>

In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM

[dotnet-policy-service]

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?

[steveisok]

This is me being nit-picky - I would move this down near where we set KnownRuntimePack and the like.

[jkotas]

runtimelab and the runtime experimental feed does not have infrastructure for servicing.

I do not think that introducing a dependency on runtimelab from dotnet/runtime is a good idea. If you really want to do that, you will have to work through the impact on servicing workflows (and likely introduce a bunch of extra infrastructure and process for dotnet/runtimelab to make that work).

[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]

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

[am11]

Can we not use PublishAot == true condition directly? MSBuild evaluates it the same way (since there is no use in any target), so it seems redundant.

[maraf]

We can. I wanted to extract it, because we weren't sure if using PublishAot for this highly experimental thing is the right choice.

[dotnet-policy-service]

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