Subject: Re: v2.35.0 DEVELOPER=1 regression

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Wed, 19 Jan 2022 02:05:25 +0100

On Tue, Jan 18 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <[email-masked]> writes:
>
>> Whereas the C11 warning is "just" recent FreeBSD && DEVELOPER=1.
>>
>> So I assumed if you weren't interested in the former before the final
>> you probably wouldn't be in the latter, but wanted to provide a more
>> narrow fix in case you were.
>
> If we muck with the inclusion of libgen.h, it then becomes a problem
> for everybody who builds on FreeBSD, not just the developer builds.
> IOW, it is not even narrower to begin with.  Giving the same
> potential breakage to everybody will make it easier to diagnose it,
> but because I do not trust -std=gnu99 on today's FreeBSD, I think it
> is a problem we do not even have to solve.

The patch I submitted could trivially have an additional "#ifdef
DEVELOPER" or equivalent, which would narrow it down even further.

The reason it doesn't is because we provide -std=gnu99 in
config.mak.dev, but that doesn't mean that we don't have to deal with
e.g. a user-supplied -std=gnu99.

Except of course if we declare that we're not going to generally support
such a thing, and you should only provide such flags via
DEVELOPER/DEVOPTS, not manually in CFLAGS, which is fair enough.

>> I.e. the point of doing it is to avoid the one-time pain of anyone
>> building new releases of git on $OLD_OS/$OLD_DISTRO not having to run
>> into the compilation error that's fixed with NO_UNCOMPRESS2=Y.
>> ...
>> If we then get this into v2.36.0 there'll be someone somewhere that
>> benefits, but I'd think the ship has sailed for most of those who'd
>> avoid the needless flag twiddling (git-packagers@ et al).
>
> I actually think it is a good thing.  It is what they brought onto
> themselves.  They can follow David's example next time.

Do you mean David Aguilar's addition of "NO_UNCOMPRESS2 = YesPlease" in
[1]? Isn't that mutually exclusive with pursuing my change to
auto-detect it[2] instead?

As noted I'm a bit "meh" on my own patch if it's not in the release. I'm
just trying to see where you stand, since you seemed to want a re-roll
of it post-release....

1. https://lore.kernel.org/git/[email-masked]/
2. https://lore.kernel.org/git/[email-masked]/