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. > 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. -Peff
