On Fri, Oct 18, 2024 at 01:24:48AM -0400, Jeff King wrote: > On Fri, Oct 18, 2024 at 06:59:17AM +0200, Patrick Steinhardt wrote: > > > > But IMHO this is a good example of where the flexibility of the first > > > approach shines. We could accommodate this platform without any real > > > cost (and indeed, we should be able to _drop_ some clar code). > > > > Well, dropping doesn't work as it breaks other projects that depend on > > the clar-features that depend on `wchar_t`. But other than that I agree > > and would like to fix this issue, also because it potentially benefits > > other users of the clar. > > So that's a rabbit hole I didn't go down in my other message. ;) > > But another traditional philosophy the Git project has had is to be very > conservative in our dependencies. And now we have this new dependency, > and already it is causing a portability problem. > > I don't think that means we should throw away the dependency. But if we > are inheriting portability problems from imported code, I think we > should consider to what degree we can lightly tweak that code to match > our project. I don't care what clar does upstream. If _we_ don't need > wchar support, we can drop it or #ifdef it out. > > 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. > > The only problem is that the platform seems to be severely broken. As > > mentioned elsewhere, we have this snippet in uclibc's "wchar.h": > > > > #ifndef __UCLIBC_HAS_WCHAR__ > > #error Attempted to include wchar.h when uClibc built without wide char support. > > #endif > > Yeah, I have no clue what's going on there. Certainly I have no problem > if you want to dig further to get confidence in the direction we choose. Yup, I'll do that, but first need additional input from the reporter. I don't have a uclibc platform, and couldn't really find obvious Docker images to reproduce the issue with. Patrick
