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

From: Jeff King <peff@peff.net>
Date: Oct 21, 2024, 19:19 UTC
Message-ID: <20241021191934.GE1219228@coredump.intra.peff.net>
In-Reply-To: <ZxLAC-c4y7_sQqzw@tapette.crustytoothpaste.net>

On Fri, Oct 18, 2024 at 08:07:39PM +0000, brian m. carlson wrote:

Show 6 quoted lines

> The difference is one set of systems has a minor incompatibility that
> requires little work to work around and has few practical effects, and
> the other tried to exclude major functionality from a tiny, ancient
> standard, the result of which is a wide variety of software that's
> broken.  (For example, ncurses normally builds a wide character
> version of the shared library in addition to the byte-based version.)

I think this is the crux of where we see things differently. I don't see wchar as major functionality, since it's not something that Git has ever used! It's an include that we pulled in via a dependency to implement a minor feature that we aren't even making use of. We can just not compile that otherwise dead code, and everything works as it did in the past. We do not have to pass judgement on uclibc's feature completeness or make life any harder for users on such systems.

(This is all assuming that we are dealing with a uclibc with disabled features in the first place. I don't think we've seen an answer to Patrick's questions about why the #error is not triggering).

-Peff