From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2 1/3] ident: stop assuming that `gw_gecos` is writable
Date: Fri, 7 Mar 2025 11:02:09 +0100 [thread overview]
Message-ID: <Z8rEIffQeVCjd_U8@pks.im> (raw)
In-Reply-To: <xmqq8qpijezc.fsf@gitster.g>
On Thu, Mar 06, 2025 at 08:33:43AM -0800, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> 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
next prev parent reply other threads:[~2025-03-07 10:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 15:44 [PATCH 0/2] Hot fixes from Git for Windows v2.49.0-rc0 Johannes Schindelin via GitGitGadget
2025-02-27 15:44 ` [PATCH 1/2] ident: stop assuming that `gw_gecos` is writable Johannes Schindelin via GitGitGadget
2025-02-27 21:15 ` Junio C Hamano
2025-02-27 15:44 ` [PATCH 2/2] meson: fix sorting Johannes Schindelin via GitGitGadget
2025-02-28 7:58 ` Patrick Steinhardt
2025-03-06 10:26 ` [PATCH v2 0/3] Hot fixes from Git for Windows v2.49.0-rc0 Johannes Schindelin via GitGitGadget
2025-03-06 10:26 ` [PATCH v2 1/3] ident: stop assuming that `gw_gecos` is writable Johannes Schindelin via GitGitGadget
2025-03-06 10:50 ` Patrick Steinhardt
2025-03-06 12:26 ` Johannes Schindelin
2025-03-06 16:33 ` Junio C Hamano
2025-03-07 10:02 ` Patrick Steinhardt [this message]
2025-03-07 18:20 ` Junio C Hamano
2025-03-06 10:26 ` [PATCH v2 2/3] meson: fix sorting Johannes Schindelin via GitGitGadget
2025-03-06 10:26 ` [PATCH v2 3/3] cmake: generalize the handling of the `CLAR_TEST_OBJS` list Johannes Schindelin via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8rEIffQeVCjd_U8@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.