Support building and deploying UCRT64 packages#178
Merged
Conversation
We plan on building Git for Windows against the more modern UCRT instead of the old MSVCRT at some point in the future (Most likely Git 3.0). To be able to do that we'll need to be able to create and publish UCRT64 packages. And to aid a smooth transition, we'll need to be able to publish MINGW64 and UCRT64 packages in parallel for a little while. Prepare our deployment workflow to deal with this. Signed-off-by: Matthias Aßhauer <[email protected]>
In git-for-windows/build-extra#711 I am preparing the `git-extra` package for the MINGW64 -> UCRT64 migration. Once that lands, the natural next step is to actually build the UCRT64 variants of the affected packages via this workflow, and for that the workflow has to know about UCRT64. The `setup-git-for-windows-sdk` action already accepts `ucrt64` as a value for its `architecture` input (which installs the UCRT64 variant of git-sdk-64), so let's reuse the same spelling as a pseudo architecture here: the runner is still `windows-latest` (UCRT64 is just an alternative MSYS2 environment on x86_64), `git.exe` is looked up under `/ucrt64/bin/`, and `MINGW_ARCH=ucrt64` is passed to `makepkg-mingw`. The `BUILD_SRC` flag stays empty, just like for `i686` and `aarch64`, because building the `.src.tar.gz` for the x86_64 variant of a package (should it also be built) already covers what would otherwise be produced for ucrt64. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <[email protected]>
In conjunction with the new `ucrt64` pseudo architecture in the `build-and-deploy` workflow, teach this script that for UCRT64 builds the MINGW package prefix is `mingw-w64-ucrt-x86_64` (not the literal `mingw-w64-ucrt64`), and that the resulting packages are deployed into the `x86_64` subdirectory of the Pacman repository, alongside the MINGW64 packages. The latter is so that the existing `git-for-windows-x86_64.db` database can keep referencing both flavors during the MINGW64 -> UCRT64 migration; the new `git-for-windows-ucrt64.db` database introduced in git-for-windows/pacman-repo#4 lives in the same `x86_64` branch of `pacman-repo` for exactly that reason. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <[email protected]>
I took most of those changes, except the idea to build the MINGW64 and UCRT64 packages in the same architecture: The long-term plan is to get rid of this multi-arch building business, and instead build the packages for a given `MINGW_ARCH` in their respective `git-sdk-*` (but for historical reasons, I think we'll keep the names `git-sdk-32` for mingw32, `git-sdk-64` for ucrt64 and `git-sdk-arm64` for clangarm64). Signed-off-by: Johannes Schindelin <[email protected]>
pull Bot
pushed a commit
to frikke/gfw-helper-github-app
that referenced
this pull request
Jun 23, 2026
Git for Windows' SDK is migrating from the MINGW64 to the UCRT64 environment, so the packages we ship need UCRT64 variants from now on. The build-and-deploy workflow already learned about the `ucrt64` pseudo architecture, which means `/deploy` can finally request those builds, but I do not want to do that by leaning on the workflow's combined run: with no explicit architecture it builds mingw32, mingw64 and ucrt64 one after another in a single job, and packages such as mingw-w64-openssl and mingw-w64-curl already take long enough that serializing a third environment on top would hurt. Dispatching one run per architecture lets them build in parallel on separate runners instead, turning the wall-clock from the sum of the three into the slowest of them. So for a regular MINGW package `/deploy` now starts individual `i686`, `x86_64` and `ucrt64` runs alongside the existing `arm64` one, rather than a single combined run plus `arm64`. git-extra is a regular MINGW package in this sense and gets the same treatment; its `.src.tar.gz` is still built exactly once, in the `x86_64` run. The set of packages that get built and deployed is unchanged; only the granularity of the runs is. Three packages stay on a single combined run: mingw-w64-git-credential- manager, mingw-w64-git-lfs and mingw-w64-wintoast are not built per architecture by us at all, but cross-compiled via Visual Studio or downloaded as pre-built artifacts for every architecture (including clangarm64) at once. mingw-w64-llvm keeps getting only the `arm64` run via `/deploy`, as before. To express that, the predicate that used to be called `needsSeparateARM64Build` is replaced by its inverse, `buildsAllArchitecturesInOneRun`, which positively names exactly those three exceptional packages. I first tried merely renaming it to `isMINGWPackage`, but that does not fit: the three exceptions are themselves MINGW packages, so a predicate that excludes them cannot honestly claim to answer "is this a MINGW package". Identifying the special cases directly keeps both the predicate and the resulting three-way dispatch (MSYS, combined, per-architecture) self-explanatory. The UCRT64 support in the build-and-deploy workflow landed in git-for-windows/git-for-windows-automation#178, and the overall SDK migration is tracked in git-for-windows/git-sdk-64#117. Assisted-by: Opus 4.8 Signed-off-by: Johannes Schindelin <[email protected]>
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
2 participants
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.
This is part of the overall effort in git-for-windows/git-sdk-64#117, and it was used to deploy the UCRT64 variants of the Git for Windows-only MINGW packages to the Pacman repository.