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

From: Jeff King <peff@peff.net>
Date: Oct 18, 2024, 05:24 UTC
Message-ID: <20241018052448.GD2408674@coredump.intra.peff.net>
In-Reply-To: <ZxHrIBCdnwdRdXAv@pks.im>

On Fri, Oct 18, 2024 at 06:59:17AM +0200, Patrick Steinhardt wrote:

Show 8 quoted lines

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

Show 6 quoted lines

> 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