On Thu, Mar 06, 2025 at 08:33:43AM -0800, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > In other words, contrary to my expectations, the `win+Meson` job is > > ill-equipped to replace the `win build` job because it exercises a > > completely different tool version/compiler flags vector than what Git > > for Windows needs. > > It is apparent that meson support is a new procedure to build our > codebase that is untested and unproven on Windows at all, given that > among all people who may have stake in Windows you are discovering > problems in it this late in the cycle. Nobody knows what other > breakages, other than something obvious and easy to catch like "ah, > compiler refuses to go further", are lurking under the radar. > > I would be reluctant to trust the build artifact out of meson-based > build on Windows after seeing your report, especially the above > part. > > A reasonable alternative may be to declare that meson-based build is > not ready yet at this point, and possibly disable win+Meson jobs to > punt and divert our engineering resources elsewhere in the meantime. > For a new thing, having an uneven support depending on the platform > early in the evolution is not unusual or to be ashamed of. I think it would be a bit sad to disable those jobs. They build and pass the test suite alright in Git itself, even though they fail downstream in Git for Windows. They help me quite a bit to ensure that I don't regress anything that already is working while I'm iterating on the current set of features. So in the end, I view them more as testing more variants of Windows than replacing what we currently have, similar to how we test Git on different Linux distributions. I have said before that I'm very willing to help to figure out any issues, regardless of which platform, and I stand by that statement -- if you see anything that is broken in this context and report the issue to me I'll jump on it immediately. > > Nevertheless, there is currently this huge push, including breaking > > changes after -rc1 and all, for switching to Meson. Therefore, we need > > to make it work, somehow, even in Git for Windows' SDK, hence this > > patch, at this point in time. > > As I said earlier already, I do not mind turning the type of this > pointer, which is only used to read from a struct member, like this > patch does. It is the right thing to do, so I'll apply. > > But I personally would not be comfortable with the product built > with "completely different tool version/compiler flags vector than > what G4W needs", even the compilation passes with just this small > change. If I were using Windows, that is. That's completely fair. The CI job we have isn't meant to verify that we have a G4W-compatible distribution falling out of it, it merely verifies that we can build and pass tests in such a "standalone" (that is, without the SDK) configuration. We might eventually want to introduce another job that _does_ use the SDK with Meson, as well, but I didn't yet see a need for that until now. Patrick
