git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: Patrick Steinhardt <ps@pks.im>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: clar unit testing framework FTBFS on uclibc systems (wchar_t unsupported)
Date: Mon, 21 Oct 2024 15:41:40 -0400	[thread overview]
Message-ID: <ZxaudJWlJbEJ3LeO@nand.local> (raw)
In-Reply-To: <20241021193024.GF1219228@coredump.intra.peff.net>

On Mon, Oct 21, 2024 at 03:30:24PM -0400, Jeff King wrote:
> On Mon, Oct 21, 2024 at 08:44:01AM +0200, Patrick Steinhardt wrote:
>
> > > Will it take us another 20 years to resolve all of the portability
> > > issues which Clar suffers from (but git-compat-util.h doesn't)?
> > > Probably not 20 years, but I don't think that it's on the complete other
> > > end of the spectrum, either.
> >
> > My assumption is that we'll iron out the issues in this release. Our
> > "git-compat-util.h" has grown _huge_, but that's mostly because it needs
> > to support a ton of different things. The Git codebase is orders of
> > magnitude bigger than the clar, so it is totally expected that it also
> > exercises way more edge cases in C. Conversely, I expect that the compat
> > headers in clar need to only be a fraction of what we have.
> >
> > I don't really understand where the claim comes from that this is such a
> > huge pain. Sure, there's been a bit of back and forth now. But all of
> > the reports I received were easy to fix, and I've fixed them upstream in
> > a matter of days.
> >
> > I'd really like us to take a step back here and take things a bit more
> > relaxed. If we see that this continues to be a major pain to maintain
> > then yes, I agree, we should likely rope in our own compat headers. But
> > from my point of view there isn't really indication that this is going
> > to be the case.
>
> I'm OK with that direction. Just to be clear, I think you've done a
> great job (as you always do) of responding to the issue promptly and
> keeping things moving forward. And you're right that there is a good
> chance that we iron out this wrinkle and never worry about it again. If
> that doesn't turn out to be the case, we can iterate from there.

Yeah, to be clear on my own position, I agree with Peff here. I was
merely suggesting that there might be more work here than we estimate,
and that it would be nice to take advantage of the experience and years
of work that have gone into git-compat-util.h if that were the case.

Certainly you have done a great job at responding promptly to any
breakages, which is greatly appreciated by myself and the project.

Thanks,
Taylor

  reply	other threads:[~2024-10-21 19:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17  3:51 clar unit testing framework FTBFS on uclibc systems (wchar_t unsupported) Bagas Sanjaya
2024-10-17 13:33 ` Patrick Steinhardt
2024-10-17 13:54   ` Patrick Steinhardt
2024-10-17 20:08     ` Taylor Blau
2024-10-17 22:21     ` brian m. carlson
2024-10-18  4:51       ` Jeff King
2024-10-18  4:59         ` Patrick Steinhardt
2024-10-18  5:24           ` Jeff King
2024-10-18  5:31             ` Patrick Steinhardt
2024-10-18 20:50               ` Taylor Blau
2024-10-21  6:44                 ` Patrick Steinhardt
2024-10-21 19:30                   ` Jeff King
2024-10-21 19:41                     ` Taylor Blau [this message]
2024-10-18 20:07         ` brian m. carlson
2024-10-21 19:19           ` Jeff King
2024-10-21 19:31             ` Jeff King
2024-10-18 13:49     ` Bagas Sanjaya
2024-10-21  6:44       ` Patrick Steinhardt

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=ZxaudJWlJbEJ3LeO@nand.local \
    --to=me@ttaylorr.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=sandals@crustytoothpaste.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).