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

[Taylor Blau <me@ttaylorr.com>]

On Fri, Oct 18, 2024 at 07:31:00AM +0200, Patrick Steinhardt wrote:
> > 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.

I'm not sure I agree wholly here. In particular, I think saying "a bit"
of pain may not be capturing the full picture.

Will it take us another 20 years to resolve all of the portability
issues which Clar suffers from (but git-compat-util.h doesn't)?
Probably not 20 years, but I don't think that it's on the complete other
end of the spectrum, either.

TBH, I would not at all be sad to see us "fork" Clar into our own tree
or have a new repository upstream that we track with submodules, etc.

Thanks,
Taylor