Add UCRT64 support to be able to build installers, portable Gits, etc#719
Merged
Conversation
The git-artifacts workflow calls `please.sh build-mingw-w64-git --only-$ARCHITECTURE`, and for the new UCRT64 pseudo architecture that produces `--only-ucrt64`. Without a matching case in `build_mingw_w64_git`, the function falls through to the `*)` catch-all and fails. Add the missing `--only-ucrt64` case that sets `MINGW_ARCH=ucrt64`, mirroring the existing `--only-aarch64` -> `clangarm64` pattern. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `edit-git-bash` check used `mingw-w64-$ARCH` to construct the Pacman package name, which only works when the architecture name happens to match the Pacman package prefix (i686, x86_64). For CLANGARM64 the prefix is `mingw-w64-clang-aarch64`, not `mingw-w64-aarch64`, so the pattern was already subtly wrong (it does not really matter because `edit-git-bash.exe` lives in the `mingw-w64-git-for-windows-addons` package nowadays, therefore that file would be included in the installer even if the check failed erroneously). Introduce a `MINGW_PACKAGE_PREFIX` variable in the MSYSTEM case block, mirroring the convention used by MSYS2 itself, and use it for the Pacman local path glob. This is a no-op for all currently supported architectures and prepares for UCRT64 where the prefix is `mingw-w64-ucrt-x86_64`. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is logic to build and include `edit-git-bash.exe` in the installer if it is not already part of the `mingw-w64-git` package, so that the installer will always have a way to modify Git Bash according to the user's choices. However, these days that executable no longer lives in the `*-git` package but instead in the `*-git-for-windows-addons` one. Let's check for that one, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For consistency with the MSYS2 convention and the installer script, rename the ad-hoc `PACMAN_ARCH` variable (which held only the architecture-specific infix, e.g. `clang-aarch64`) to the full `MINGW_PACKAGE_PREFIX` (e.g. `mingw-w64-clang-aarch64`). The two call sites that constructed `mingw-w64-$PACMAN_ARCH-<pkg>` now simply use `$MINGW_PACKAGE_PREFIX-<pkg>`. No functional change for any architecture. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Same pattern as the installer and mingit scripts: introduce `MINGW_PACKAGE_PREFIX` and use it for the `pacman -Ql` call that discovers which executables live in `libexec/git-core/`. The nuget script only runs for x86_64, but the naming is now consistent with the rest of the release scripts. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
8b69f3b to
dd3b5ce
Compare
Add the `UCRT64` case arms to the MSYSTEM switch in the installer, portable, etc `release.sh` scripts. The installer gets a filename suffix of `ucrt64` via an Inno Setup define (following the same pattern as arm64). The archive and portable scripts derive the artifact suffix directly from the case block. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dd3b5ce to
46930c7
Compare
In MSYS2 parlance, there is an architecture-specific $MINGW_PACKAGE_PREFIX, and we should use _that_ instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `bundle_pdbs` function strips the architecture-specific prefix from Pacman package names using sed to produce architecture-neutral names like `mingw-w64-git`. The existing alternation handled `-clang-<arch>` (for CLANGARM64) and `-<arch>` (for i686/x86_64), but not `-ucrt-<arch>` (for UCRT64). As a result, `mingw-w64-ucrt-x86_64-git` was not recognized and the function died with "Could not determine Git version". Add `-ucrt-[^-]*` to the alternation so that the two-segment `ucrt-x86_64` prefix is stripped correctly. Additionally, the `bundle_pdbs` function iterates over architectures and maps each to a `pacman_arch` and `artifact_suffix`. The previous commit fixed the package-name prefix stripping, but the architecture case block itself still lacked a `ucrt64` entry, causing "Unhandled architecture: ucrt64" when the function reached the per-architecture download loop. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the UCRT64 variant of the Git for Windows SDK, the `openssl` package is inherited from MSYS2, and not shadowed by Git for Windows' own built versions. The reason that Git for Windows builds its own versions of OpenSSL is historical: In the early days of MSYS2, package updates were somewhat sporadic and came in spurts, whereas the Git for Windows project needed to pick up OpenSSL updates very swiftly when this addressed vulnerabilities. In the meantime, it is the other way round: Git for Windows often lags behind MSYS2 in updating OpenSSL packages to newer versions, and therefore there is now good reason to stop shadowing MSYS2's versions, see also git-for-windows/git#6243. Therefore, there's absolutely no reason for the Git for Windows project to start building OpenSSL for UCRT64 only to drop it almost immediately. As a consequence, no PDB files are available for OpenSSL, and we'll simply not even try to include them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
7b89cad to
02e46d0
Compare
mjcheetham
approved these changes
Jun 22, 2026
dscho
added a commit
to git-for-windows/git-for-windows-automation
that referenced
this pull request
Jun 22, 2026
In git-for-windows/git-sdk-64#117, a long-running PR, the UCRT64 flavor of Git for Windows' SDK is being established. Multiple packages have already been deployed, and now, in conjuction with git-for-windows/build-extra#719, it is time to build installers.
pull Bot
pushed a commit
to frikke/gfw-helper-github-app
that referenced
this pull request
Jun 23, 2026
Git for Windows is gaining a UCRT64 flavor, and I want the `/git-artifacts` command (as well as the snapshot builds that cascade from a `tag-git` run) to build those bits alongside the existing x86_64, i686 and aarch64 ones. The actual build logic lives in two other repositories: build-extra learns to assemble installers, portable Gits and the like from a UCRT64 SDK (git-for-windows/build-extra#719), and the git-artifacts pipeline gains `ucrt64` as a valid `architecture` choice (git-for-windows/git-for-windows-automation#179). This helper is what dispatches those pipeline runs, so once those two pull requests are merged it needs to start asking for the fourth architecture, too. `triggerGitArtifactsRuns()` is the single place both entry points funnel through: the `/git-artifacts` slash command when a `tag-git` run already succeeded, and the automatic cascade when a `tag-git` check-run completes. Adding `ucrt64` to its architecture list therefore covers both without touching anything else. I deliberately leave the `upload-snapshot` cascade and the `/release` command at the three established architectures for now, so the UCRT64 bits are built but not yet published anywhere. A completing `git-artifacts-ucrt64` check-run does still trigger the cascade handler, because that handler matches on the `git-artifacts-` name prefix, but it only ever looks up and forwards the three standard architectures' run IDs. The extra completion is therefore harmless and, conveniently, a failing UCRT64 build will not hold back the snapshot of the other three. Assisted-by: Opus 4.8 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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
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 PR adjusts the scripts in
build-extrato support buildingmingw-w64-gitand the installers/portable Gits/etc.