Hi Patrick, On Thu, 6 Mar 2025, Patrick Steinhardt wrote: > On Thu, Mar 06, 2025 at 10:26:18AM +0000, Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > Now, why does this not trigger in CI? The answer is as simple as it is > > puzzling: The `win+Meson` job completely side-steps Git for Windows' > > development environment, opting instead to use the GCC that is on the > > `PATH` in GitHub-hosted `windows-latest` runners. That GCC is pinned to > > v12.2.0 and targets the UCRT (unlikely to change any time soon, see > > https://github.com/actions/runner-images/blob/win25/20250303.1/images/windows/toolsets/toolset-2022.json#L132-L141). > > That is in stark contrast to Git for Windows, which uses GCC v14.2.0 and > > targets MSVCRT. Git for Windows' `Makefile`-based build also obviously > > uses different compiler flags, otherwise this compile error would have > > had plenty of opportunity in almost 14 years to surface. > > Oh, interesting. I didn't even know that the Windows runners had GCC in > their PATH, and thus I didn't expect it to use that compiler at all. On > GitLab for example we can see that it uses the MSVC compiler as I did > expect [1]: > > Activating VS 17.10.2 > C compiler for the host machine: cl (msvc 19.40.33811 "Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64") > C linker for the host machine: link link 14.40.33811.0 > > But you're right, on GitHub that's not the case: > > C compiler for the host machine: gcc (gcc 12.2.0 "gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 12.2.0") > C linker for the host machine: gcc ld.bfd 2.39 > > We can easily fix that by passing the `--vsenv` flag to Meson. I'll send > a patch soonish. > > Patrick > > [1]: https://gitlab.com/gitlab-org/git/-/jobs/9324989037#L95 > [2]: https://github.com/git/git/actions/runs/13686408338/job/38270746786#step:5:15 Please do not invest more time on the Visual Studio support via Meson. No contributor will use this, and I want to stop spending my time on this. The user experience of configuring a Visual Studio build via Meson is just too weak compared to the ease of CMake-based builds, and while not many Visual Studio users are familiar with CMake, even dramatically less will even so much as know about Meson. I plan on dropping all pretense that Git supports Visual Studio-based contributions soon after v2.49.0 comes out, e.g. by deleting the CMake definition and also deleting whatever Meson-specific stuff I can get away deleting in Git for Windows. It was not worth the time I invested. Ciao, Johannes