ci(mcpp): track mcpp 2026.8.17.1 - #7
Merged
Merged
Conversation
Not a floor — this job's path is unchanged by the release. It is tracked because 2026.8.17.1 binds the Windows SDK per ORIGIN (mcpp#448), and this job is the only place the `msvc@system` half runs against a real Visual Studio: the search chain, VSINSTALLDIR precedence included, has to stay exactly as it was. The managed half — where `WindowsSdkDir` is now ignored — is covered by mcpp's own CI. One thing does change: the resolved SDK version now enters the runtime contract hash as `ucrt@<version>`, so the first build on this version rebuilds from cold. One-off, not a regression.
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.
mcpp 2026.8.17.1 gives the Windows SDK and the runtime the axes the compiler already had (mcpp-community/mcpp#448).
This job's path is unchanged by it, and that is the point of running it: 2026.8.17.1 resolves the Windows SDK per origin —
msvc@<toolset>WindowsSdkDirignored, out loudmsvc@system← this jobWindowsSdkDirfirstand this job is the only place the
msvc@systemhalf runs against a real Visual Studio with an exportedVSINSTALLDIR. If the split had disturbed that chain, the toolset assertion here goes red — which is exactly why the version is tracked rather than left alone.One real change: the resolved SDK version now enters the runtime contract hash as
ucrt@<version>, so the first build on this version rebuilds from cold. One-off, and the reason it exists is that two SDKs used to share one cache key.