Add the mingw64 pseudo architecture, and default to ucrt64 - #1454
Conversation
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
Oy vey, I forgot to run |
We're just about to "flip the switch", when Git for Windows' SDK will no longer be a MINGW64 one but a UCRT64 one, for full details see git-for-windows/git-sdk-64#117. Once that happens, we need `/ucrt64/bin/` to be in the `PATH` so that the `git.exe` is still found after that switch flip. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Moving git-sdk-64's main branch to UCRT64 will replace MINGW64 in the default x86_64 SDK. Allow consumers to select the preserved mingw64 branch explicitly. This depends on build-extra accepting --architecture=mingw64: git-for-windows/build-extra#739 Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
740702f to
b098cf6
Compare
In theory we could avoid that hack by delaying the migration of the default and the sdk
|
The problem is not our CI jobs. It's upstream Git's. And if we delayed, then we couldn't migrate in time for v2.56.0-rc0 (and would have to wait for the next version). I'm not willing to delay that much. Better get it over with. |
The information which commit OID was checked out is quite useful to analyze workflow runs, especially when investigating bugs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I tried to get gitgitgadget/git#2195 merged into upstream Git's `master` branch in time for the big migration from MINGW64 to UCRT64 (because MSYS2 deprecated the former, see git-for-windows/git-sdk-64#117 for full details). Without that patch series, trying to compile Git will fail either with: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 or with ld.exe: unrecognized option '--large-address-aware' ld.exe: use the --help option for usage information The wheels of the Git mailing list turn slowly, though, and therefore this won't happen in time for v2.56.0-rc0, which is when we _have_ to complete that migration because we said that Git for Windows v2.55.0 would be the last to support Windows 8.1, and that UCRT64 migration was the reason for that. To allow for Git's CI, which depends transitively on Git for Windows' SDK (by virtue of using the minimal subset in every `win-build` and `win-test` job), to pass, still, let's introduce a hack: In Git's CI definition, the source code is checked out first, and we can detect whether the patch series has been applied or not by looking for the tell-tale `_USE_32BIT_TIME_T`. If absent, the patches are missing, and we will automagically fall back to using the `mingw64` variant, which successfully compiles. The downside is that this variant is a bit costly because it has to perform a partial, shallow clone. But the alternative (a failing CI) would be worse. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To support Git for Windows' ongoing migration from MINGW64 to UCRT64, let's adapt this Action to use the `ucrt64` flavor by default. This way, kinks can be sorted out before the migration of `git-sdk-64`'s `main` branch actually concludes, and we can leisurely adapt the code for the `x86_64` flavor in a subsequent PR after that migration. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
b098cf6 to
e2650f2
Compare
I wasn't trying to say that our CI jobs are the problem, but that it's quicker for us to make small modifications to our CI jobs than to wait for patches to land in git.git and that if all our CI jobs including our release automation would explicitly request |
Ah. Now I understand. I'd like to avoid that, though. We're already spending way too much effort working around upstream, and first switching everything to |
3 participants
This PR is a bit time-critical, as I need it to be able to merge git-for-windows/git-sdk-64#117 in preparation for Git v2.56.0-rc0, which is due later today. Unfortunately, I didn't manage to get gitgitgadget/git#2195 accepted into upstream Git's
masterbranch in time, so this PR gets a bit ugly.Here's the thing: I need to migrate Git for Windows' SDK from MINGW64 to UCRT64. The reason is that MSYS2 deprecated the former, and so we have to migrate to the latter. The natural inflection point to do this would have been Git v3.0 but there is no clarity to be had about any concrete timeline regarding this big milestone, so the next best thing we in the Git for Windows project can do is to tie that migration (which comes at the price of dropping support for Windows 8.1) to Git for Windows v2.56.0, hence the note in our release notes (also in our previous v2.55.* announcements).
Migrating this here GitHub Action to UCRT64 comes with a couple of challenges. First of all, the MSYSTEM environment variable and the paths of tools like
gcc.exechange. This should all be handled transparently via this PR because we no longer default tox86_64, but we now default toucrt64, where these variables are already set correctly (as verified by theci-artifactsworkflow).The next building block of this PR is that
x86_64will be broken for a short time window once git-for-windows/git-sdk-64#117 is merged. I already have a branch to adapt to that: https://github.com/git-for-windows/setup-git-for-windows-sdk/compare/adapt-to-ucrt64-migration-of-git-sdk-64. I will open a PR once the PR build has a chance to succeed (i.e. whengit-sdk-64migrated to UCRT64), and we will hopefully be able to merge it and release a new version ofsetup-git-for-windows-sdkswiftly, to keep that window during whicharchitecture: x86_64is broken to a minimum.The biggest snag is that upstream Git didn't accept my patch series yet. Without it, upstream Git won't compile under UCRT64. So if we simply switched the default architecture to
ucrt64, we would break every single CI build of git/git (but obviously not git-for-windows/git, because obviously I accepted those patches already). To avoid having these CI failures hit innocent Git contributors, here comes the really ugly part of this PR. This GitHub Action learns about internal details of the Git project, details that it should not have needed to know about. It looks for a tell-tale in the current working directory to determine whether it is supposed to run the CI build on an unpatched Git source code that would fail to compile under UCRT64, and if that's the case, it will fall back to initializing a MINGW64 minimal SDK instead. I know this is ugly. It is still the best I can do under the circumstances. It was not my choice to have it this way. At least this way we can go forward with the migration without being blocked.To demonstrate that this hack works, I ran the Git CI on Git for Windows' current
main(plus minimal patches to use this PR branch), you can see that it uses UCRT64 here), and also on Git'smasterbranch (plus same patches, see the warning that it had to fall back to MINGW64, and the correctly-setMSYSTEMhere).