Skip to content
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-mt] Fix pack/build issues in threaded builds #75162

Merged
merged 6 commits into from
Sep 7, 2022

Conversation

lambdageek
Copy link
Member

Addresses the following from #74654:

  • dotnet.worker.js missing from the runtime pack
  • WorkloadManifest.targets.in uses WasmEnableThreading instead of WasmEnableThreads
  • The CoreLibs in the multithread and perftrace build variants don't define the correct feature flags.
  • dotnet new wasmbrowser creates browser.csproj, not <dirname>.csproj

…ithread'

Also define the perf-tracing feature flag for the threaded and
perf-tracing build variants.
not WasmEnabelThreading.

Conversely, use `WasmEnablePerfTracing`, not `WasmEnablePerfTrace`.
eng/liveBuilds.targets Outdated Show resolved Hide resolved
@lambdageek
Copy link
Member Author

/backport to release/7.0

@github-actions
Copy link
Contributor

github-actions bot commented Sep 6, 2022

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3003289156

@github-actions
Copy link
Contributor

github-actions bot commented Sep 6, 2022

@lambdageek backporting to release/7.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: [wasm-mt] Build the threaded CoreLib if MonoWasmBuildVariant is 'multithread'
Using index info to reconstruct a base tree...
M	src/mono/System.Private.CoreLib/System.Private.CoreLib.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/mono/System.Private.CoreLib/System.Private.CoreLib.csproj
Applying: Also fixup the BCL assemblies
Applying: [wasm-mt] look for WasmEnableThreads in user projects
Using index info to reconstruct a base tree...
A	src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets.in
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets.in deleted in HEAD and modified in [wasm-mt] look for WasmEnableThreads in user projects. Version [wasm-mt] look for WasmEnableThreads in user projects of src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets.in left in tree.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0003 [wasm-mt] look for WasmEnableThreads in user projects
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@lambdageek
Copy link
Member Author

lambdageek commented Sep 6, 2022

Edit it's because the workload got split up into a net6 and a net7 version in the release/7.0 branch

Not sure why the backport didn't work. it backported cleanly locally. I'll do a manual one in an hour...

@lambdageek
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@lambdageek lambdageek merged commit 703dc8d into dotnet:main Sep 7, 2022
lambdageek added a commit to lambdageek/runtime that referenced this pull request Sep 8, 2022
Foward port changes from `release/7.0` dotnet#75171
that were not included in `main` dotnet#75162

- when building the InteropServices.JavaScript library, enable
threading if MonoWasmBuildVariant is set appropriately.  One
consequence is that the runtime will (correctly) install the browser
synchronization context on the main thread.

- for workload build testing, unset MonoWasmBuildVariant when creating
the non-threaded runtime
lambdageek added a commit that referenced this pull request Sep 12, 2022
Foward port changes from `release/7.0` #75171
that were not included in `main` #75162

- when building the InteropServices.JavaScript library, enable
threading if MonoWasmBuildVariant is set appropriately.  One
consequence is that the runtime will (correctly) install the browser
synchronization context on the main thread.

- for workload build testing, unset MonoWasmBuildVariant when creating
the non-threaded runtime
@ghost ghost locked as resolved and limited conversation to collaborators Oct 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants