You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically, Git for Windows' primary focus was on the 64-bit builds ever since switching to MSYS2 in 2015. Since makepkg-mingw can build both MINGW32 and MINGW64 packages as long as the toolchain and required libraries are present for both, for convenience we did just that.
For MSYS packages, this was never possible, as you can either run with an i686 MSYS2 runtime or with an x86_64 one, and the MSYS toolchain is restricted by the MSYS2 runtime with which it is running. Therefore, i686 MSYS packages always had to be built in git-sdk-32, and x86_64 ones in git-sdk-64.
With the advent of Windows/ARM64, the MINGW strategy was no longer working because it isn't (currently) possible to cross-compile from an x86_64 machine, and besides, MINGWARM64 does not exist (yet). Therefore, we adopted kind of a hybrid approach where the i686 and x86_64 variants of mingw-w64-* packages are built in git-sdk-64 and the aarch64 variants in git-sdk-arm64.
There is an additional exception to that rule that muddies the waters even more: When building the artifacts for a Git for Windows release or snapshot, mingw-w64-i686-git is built using git-sdk-32. (The snapshot builds before git-for-windows/git-for-windows-automation#109 still used git-sdk-64 to build both mingw-w64-i686-git and mingw-w64-x86_64-git, but as of that PR the former uses git-sdk-32.)
It is time to rethink this hybrid, inconsistent strategy. The current state of Git for Windows' support of i686 builds is that as per #5394, we will stop building i686 installers soon, and in four years, we will stop building i686 artifacts altogether. Having to carry around all that i686 stuff is also expensive, as e.g. the clone of git-sdk-64, even the shallow one, that is used to build MSYS packages still checks out ~200MB worth of /mingw32/ files (and needs to transfer the corresponding data from the server).
Also, from a purely aesthetic point of view, it is much more elegant to separate the support per CPU architecture via the git-sdk-* repository boundary.
So let's stop building mingw-w64-i686-* packages in the same job as the mingw-w64-x86_64-* ones (and use git-sdk-32 for the former instead of git-sdk-64).
The tasks needed to bring these changes about are:
The git-artifacts CI run in git-sdk-64 needs to stop building mingw-w64-i686-git (technically, this should be done anyway)
The build-and-deploy GitHub workflow needs to require the architecture and adjust the comment of that input. It's likely a good idea to introduce a new value, e.g. all, for "building" packages like git-credential-manager that do not use the git-sdk-* repository's files to build the executables.
Historically, Git for Windows' primary focus was on the 64-bit builds ever since switching to MSYS2 in 2015. Since
makepkg-mingw
can build bothMINGW32
andMINGW64
packages as long as the toolchain and required libraries are present for both, for convenience we did just that.For MSYS packages, this was never possible, as you can either run with an i686 MSYS2 runtime or with an x86_64 one, and the MSYS toolchain is restricted by the MSYS2 runtime with which it is running. Therefore, i686 MSYS packages always had to be built in
git-sdk-32
, and x86_64 ones ingit-sdk-64
.With the advent of Windows/ARM64, the MINGW strategy was no longer working because it isn't (currently) possible to cross-compile from an x86_64 machine, and besides, MINGWARM64 does not exist (yet). Therefore, we adopted kind of a hybrid approach where the i686 and x86_64 variants of
mingw-w64-*
packages are built ingit-sdk-64
and the aarch64 variants ingit-sdk-arm64
.There is an additional exception to that rule that muddies the waters even more: When building the artifacts for a Git for Windows release or snapshot,
mingw-w64-i686-git
is built usinggit-sdk-32
. (The snapshot builds before git-for-windows/git-for-windows-automation#109 still usedgit-sdk-64
to build bothmingw-w64-i686-git
andmingw-w64-x86_64-git
, but as of that PR the former usesgit-sdk-32
.)It is time to rethink this hybrid, inconsistent strategy. The current state of Git for Windows' support of i686 builds is that as per #5394, we will stop building i686 installers soon, and in four years, we will stop building i686 artifacts altogether. Having to carry around all that i686 stuff is also expensive, as e.g. the clone of
git-sdk-64
, even the shallow one, that is used to build MSYS packages still checks out ~200MB worth of/mingw32/
files (and needs to transfer the corresponding data from the server).Also, from a purely aesthetic point of view, it is much more elegant to separate the support per CPU architecture via the
git-sdk-*
repository boundary.So let's stop building
mingw-w64-i686-*
packages in the same job as themingw-w64-x86_64-*
ones (and usegit-sdk-32
for the former instead ofgit-sdk-64
).The tasks needed to bring these changes about are:
git-artifacts
CI run ingit-sdk-64
needs to stop buildingmingw-w64-i686-git
(technically, this should be done anyway)build-and-deploy
GitHub workflow needs to require thearchitecture
and adjust the comment of thatinput
. It's likely a good idea to introduce a new value, e.g.all
, for "building" packages likegit-credential-manager
that do not use thegit-sdk-*
repository's files to build the executables./deploy
slash command (handled by the GitForWindowsHelper GitHub App) needs to trigger separatei686
/x86_64
runs instead of a combined one, but be careful to still only do that unless the MINGW package is not actually built using thegit-sdk-*
.mingw-w64-i686-*
Pacman packages that are installed ingit-sdk-64
need to be removed (probably using a one-off GitHub workflow run in agit-sdk-64
branch).I likely forgot tasks, i.e. this list is subject to be amended.
The text was updated successfully, but these errors were encountered: