Skip to content

Add UCRT64 support to be able to build installers, portable Gits, etc#719

Merged
dscho merged 9 commits into
mainfrom
please-build-mingw-w64-git-ucrt64
Jun 22, 2026
Merged

Add UCRT64 support to be able to build installers, portable Gits, etc#719
dscho merged 9 commits into
mainfrom
please-build-mingw-w64-git-ucrt64

Conversation

@dscho

@dscho dscho commented Jun 19, 2026

Copy link
Copy Markdown
Member

This PR adjusts the scripts in build-extra to support building mingw-w64-git and the installers/portable Gits/etc.

@dscho dscho self-assigned this Jun 19, 2026
dscho added 5 commits June 19, 2026 15:06
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>
@dscho dscho force-pushed the please-build-mingw-w64-git-ucrt64 branch from 8b69f3b to dd3b5ce Compare June 19, 2026 13:50
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>
@dscho dscho force-pushed the please-build-mingw-w64-git-ucrt64 branch from dd3b5ce to 46930c7 Compare June 19, 2026 15:55
@dscho dscho marked this pull request as ready for review June 19, 2026 15:55
dscho added 3 commits June 20, 2026 09:49
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>
@dscho dscho force-pushed the please-build-mingw-w64-git-ucrt64 branch from 7b89cad to 02e46d0 Compare June 20, 2026 08:24
@dscho dscho changed the title More UCRT64 support Add UCRT64 support to be able to build installers, portable Gits, etc Jun 20, 2026
@dscho dscho merged commit 8a5e1f6 into main Jun 22, 2026
14 checks passed
@dscho dscho deleted the please-build-mingw-w64-git-ucrt64 branch June 22, 2026 08:17
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants