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

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