Merged
Conversation
xen2
force-pushed
the
master
branch
2 times, most recently
from
ab329f3 to
482bd28
Compare
xen2
force-pushed
the
feature/parallel-build
branch
5 times, most recently
from
0e90097 to
47d25bd
Compare
…ojects Drop Pack from _StrideProjectReferenceGraphicsApiDependent's MSBuild dispatch. Pack re-entry was a source of 'same project built twice with different globals' under parallel MSBuild; the normal ProjectReference walk handles Build, and Pack runs separately on consuming projects. With Pack gone, the explicit Targets attribute is redundant (Build is the default). Set StrideSkipAutoPack=true on test projects — they don't produce their own .nupkg. Add StrideSkipAutoPack to GlobalPropertiesToRemove on the Stride.Core.Assets.CompilerApp ProjectReference so the property stays local: CompilerApp still needs its own .nupkg in bin\packages\ for the test's AssetCompiler run.
Non-API-dependent middle projects (e.g. Stride.Engine, built with default API) re-export the wrong-variant ssdeps through the reference graph; under parallel MSBuild the direct API-dependent reference races with the transitive one on the same output filename.
xen2
force-pushed
the
feature/parallel-build
branch
5 times, most recently
from
9b9958e to
aa9b560
Compare
…ches Fixes obj/ file-lock races between competing cache entries that targeted the same per-project obj path. Two independent sources of cache-key divergence were aligning on the output path but not on the project instance: 1. StrideGraphicsApi propagation through ProjectReferences: _MSBuildProjectReferenceExistent includes transitive refs auto-promoted from project.assets.json by the .NET SDK — those items don't carry any per-ref attribute, so classify refs by target filename against a central list instead. API-dep refs get StrideGraphicsApi via AdditionalProperties (cache-key-contributing); non-API-dep refs strip it so different-API callers collapse to one cache entry per (project, TF). 2. Stride.Core.CompilerServices analyzer ref: The explicit SetTargetFramework="TargetFramework=netstandard2.0" was redundant (CompilerServices is single-TF netstandard2.0) and also put TargetFramework into the consumer-ref dispatch globals, creating a cache entry distinct from the slnf-direct outer dispatch. Both entries then raced on the same obj/ path. Manifested most visibly in test-*-simple.yml CI where many small test projects referenced the analyzer and slnf also built it directly. Also: unescape StrideGraphicsApis so a command-line '%3B' separator survives as real item splits in multi-API builds; drop the competing no-SGA query-dispatch cache entry created by _ComputeTargetFrameworkItems.
xen2
force-pushed
the
feature/parallel-build
branch
from
aa9b560 to
15e2c18
Compare
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Details
Parallel MSBuild in CI
This PR re-enables parallel MSBuild (
-maxcpucount) across the build and test workflows that had been pinned to-m:1as a workaround for race conditions.In practice, CI builds seems 10–30% faster.
What changed
-m:1from build/test workflows (runtime, tests, platform builds) — they now run at full CPU parallelism by default like a normaldotnet build.Stride.GraphicsApi.InnerBuild.targets+Stride.AssemblyProcessor.targets+Sdk.targetsso projects can be safely built in parallel regardless of whether you use single-API, multi-API, or platform-specific configurations.<StrideGraphicsApiDependent>true</StrideGraphicsApiDependent>in the csproj and register the project in the SDK's list (new). The SDK validates this at build time and errors with a clear message pointing to the missing part (if any).Verified
-p:StrideGraphicsApis=Direct3D11;Direct3D12;Vulkan)msbuild /mwas already enabling parallelismTypes of changes
Checklist