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:

quoted

quoted

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.

quoted

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