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
