Re: clar unit testing framework FTBFS on uclibc systems (wchar_t unsupported)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

My thinking / response was mostly just: git-compat-util.h has many
subtle fixes we've accumulated through battle-testing. To the point that
I don't think we even know which ones are important and which are not
anymore. That's why our guidelines say that everything should include it
first, rather than trying to handle system headers themselves. Clar
violates that rule, and if it were original code within Git it probably
would have been flagged in review as such. But since it's imported,
there's some tension there between making the code as Git-like as
possible, and keeping it easy to track upstream.

I tend to err on the "fork and make it Git-like" side of that line, but
certainly there is an argument for the other way. Anyway, let's deal
with this wchar.h issue and then see if it ever even comes up again.

-Peff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux