-
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][mt] Fix System.Threading.Tasks.Parallel build #97505
[wasm][mt] Fix System.Threading.Tasks.Parallel build #97505
Conversation
@@ -7,7 +7,7 @@ | |||
</PropertyGroup> | |||
<PropertyGroup> | |||
<TargetPlatformIdentifier>$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)'))</TargetPlatformIdentifier> | |||
<FeatureWasmThreads Condition="'$(TargetPlatformIdentifier)' == 'browser' and '$(MonoWasmBuildVariant)' == 'multithread'">true</FeatureWasmThreads> | |||
<FeatureWasmThreads Condition="'$(TargetOS)' == 'browser' and '$(MonoWasmBuildVariant)' == 'multithread'">true</FeatureWasmThreads> |
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.
what is the old thing, TargetPlatformIdentifier
? Was it empty? I found:
4. Set the `TargetPlatformIdentifier` property in the project to be able to condition on it in properties in the project file. |
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.
Why not do it consistently in all project files if TargetPlatformIdentifier
doesn't work well ?
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.
it is the platform identifier from $(TargetFramework). I think it would have the value 'browser' if the target framework was something like net9.0-browser
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.
That's interesting. TargetFramework
is not in the form of net9.0-browser
. We have quite a few places where we use the same condition, not connected with threading. It should mean that they are not triggered, e.g.
<ItemGroup Condition="'$(TargetPlatformIdentifier)' == 'unix' or '$(TargetPlatformIdentifier)' == 'browser' "> |
Line 19 in 135fec0
<EmitCompilerGeneratedFiles Condition="'$(Configuration)' == 'Debug' and '$(TargetPlatformIdentifier)' == 'browser'">true</EmitCompilerGeneratedFiles> |
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.
@radekdoulik i didn't understand why/how you resolved this. We have many same conditions in the other project files. Do they all work or not ? Could we have them consistent ?
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 discourage using TargetOS
to vary builds (except in some special cases for tests) because it defaults to the host OS if a target OS is not explicitly passed in, which is the case if you build a library from VS or in the "allConfiguration" CI build.
The correct solution here is to add $(NetCoreAppCurrent)-browser
TFM and use TargetPlatformIdentifier
in the condition.
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.
@akoeplinger, @lewing I am curious, how are the produced assemblies used further in the process. So in this case, where does the assembly built with net9.0 TFM ends up and where the net9.0-browser one. I imagine they end up in the right Sdk and workload so that users projects get the right assembly?
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.
I see many <IgnoreForCI Condition="'$(TargetOS)' == 'browser'">true</IgnoreForCI>
but I don't know what IgnoreForCI
does.
There are also many <DebuggerSupport Condition="'$(DebuggerSupport)' == '' and '$(TargetOS)' == 'browser'">true</DebuggerSupport>
Overall we have '$(TargetOS)' != 'browser'
15x and '$(TargetOS)' == 'browser'
126x
Should we fix it all ?
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.
So in this case, where does the assembly built with net9.0 TFM ends up and where the net9.0-browser one. I imagine they end up in the right Sdk and workload so that users projects get the right assembly?
Yes the build system will select the right assets when building a specific runtime pack, based on the RID fallback graph in PortableRuntimeIdentifierGraph.json
[..] but I don't know what IgnoreForCI does.
IgnoreForCI skips sending a test project to helix, it is just an optimization for projects where all tests are disabled/skipped for whatever reason so that we don't waste resources sending and running a helix workitem where 0 tests are executed.
In theory the correct way would be to add additional browser TFMs here too but it'd make build times longer and test projects are always built for a specific target OS so we let it slide. The important part is that we only do this in tests, not in the src csproj. I've checked and only System.Linq.Parallel.csproj is affected (#97539 has the fix).
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.
And just to be clear: the current way "works" because in CI/official builds we'll always have TargetOS=browser
, the correct way is mostly important for VS scenarios e.g. you should be able to use the TFM dropdown in VS to select a different config and hit build to build the "browser' version, this likely won't work today anyway because of additional properties like MonoWasmBuildVariant.
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
note that you need to look into AzDO I will change it soon, see |
Orange means something is broken. System.Runtime.InteropServices.JavaScript.Tests I'm working on in #97441 and it's unrelated to you System.Numerics.Tensors.Tests and System.Numerics.Tensors.Net8.Tests are broken by #97295 unrelated to you |
these are unrelated, right, so it should be fine to merge it? |
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.
Please fix all the other projects which could have the same problem before you merge this.
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
There are few more places to fix. I will do it in a following PR as it might need more work in case there are build issues.
I was thinking about adding the logic to the |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
Fixes #91541
Fixes #91579
Fixes #91581
Fixes #91582
Fixes #91583
Fixes #97396
Fixes #97440