-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasm] Integrate naot-llvm into workload manifest #101801
Conversation
Tagging subscribers to 'arch-wasm': @lewing |
...ono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in
Outdated
Show resolved
Hide resolved
# Conflicts: # eng/Versions.props
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? |
...ono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in
Outdated
Show resolved
Hide resolved
</PropertyGroup> | ||
|
||
<ItemGroup Condition="'$(_IsUsingNativeAOT)' == 'true' and ('$(RuntimeIdentifier)' == 'browser-wasm' or '$(RuntimeIdentifier)' == 'wasi-wasm')"> | ||
<KnownILCompilerPack Remove="Microsoft.DotNet.ILCompiler" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is me being nit-picky - I would move this down near where we set KnownRuntimePack
and the like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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. Anyway, if the current scope is too deep, I'm happy to reduce it to follow the original goals. |
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 |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
# Conflicts: # eng/Versions.props # eng/testing/scenarios/BuildWasmAppsJobsList.txt # src/mono/wasm/Wasm.Build.Tests/Common/BuildEnvironment.cs
@@ -1,6 +1,7 @@ | |||
<!-- Licensed to the .NET Foundation under one or more agreements. The .NET Foundation licenses this file to you under the MIT license. --> | |||
<Project> | |||
<PropertyGroup> | |||
<_IsUsingNativeAOT Condition="'$(PublishAot)' == 'true'">true</_IsUsingNativeAOT> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can. I wanted to extract it, because we weren't sure if using PublishAot
for this highly experimental thing is the right choice.
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
TODO
Visual C++ Redistributable(not needed after removal of LLVMSharp dependency)BrowserWorkloadEnabled
Allow to use emscripten workload separately emsdk#869ImportRuntimeIlcPackageTarget
target override in naot-llvmUpdate(fixed in naot branch)Microsoft.NETCore.App
(KnownFrameworkReference) version to correct version of JS interop generator or ship the generator other wayAn alternative approach as a result for this experimentation
In combination with current NativeAOT-LLVM setup these props will allow to use emscripten workload with NativeAOT-LLVM