On Fri, Oct 18, 2024 at 04:50:52PM -0400, Taylor Blau wrote: > On Fri, Oct 18, 2024 at 07:31:00AM +0200, Patrick Steinhardt wrote: > > > Overall, I'm a little sad to see all of the #includes in clar.c. We have > > > spent 20 years building up git-compat-util.h to meet our needs for > > > portability, and there are lots of subtle bits in there about what is > > > included and when, along with various wrappers. And now we have a new > > > subsystem which doesn't use _any_ of that, and has its own set of > > > includes and wrappers. It seems inevitable that we are going to run into > > > cases where a platform we support isn't handled by clar, or that we'll > > > have to duplicate our solution in both places. I wish it were just using > > > git-compat-util.h. I know that means essentially forking, but I think I > > > may prefer that to inheriting some other project's portability problems. > > > > Well, I'm of a different mind here. It sure is more work for now, and I > > have been chipping away at the issues. But in the end, it's not only us > > who benefit, but the overall ecosystem because others can use clar on > > more or less esoteric platforms, too. It's part of the reason why I have > > been advocating for clar in the first place: we have a good relationship > > to its maintainers, so it is easy to upstream changes. > > > > So yes, right now we feel a bit of pain there. But that's going to go > > away, and from thereon everyone benefits. > > I'm not sure I agree wholly here. In particular, I think saying "a bit" > of pain may not be capturing the full picture. > > 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. > TBH, I would not at all be sad to see us "fork" Clar into our own tree > or have a new repository upstream that we track with submodules, etc. I don't see any reason for this. If we eventually figure out that we want to rope in our own compat headers we can wire up support for this without forking clar. In any case, I'll reroll my patch series that updates the clar today or tomorrow to incorporate a fix for the reported issue. Patrick
