Re: v2.35.0 DEVELOPER=1 regression

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I'd like to have it too, but for context needing to add NO_UNCOMPRESS2=Y
> (which Junio's punted on for the final[2]) is a much more widespread
> issue of needing new post-install build tweaking than this issue that
> only affects developer builds on FreeBSD.

I hate it when people misrepresent what I said, even in an attempt
to spite me.  For the "check ZLIB_VERSION_NUM" topic, I gave you
specific things that needs to be different from the version posted
with reasons, fully expecting that a better version of the patch to
materialize soon (knowing how proliferate you can be when you want
to) to give us enough time to assess the potential damage.

I wouldn't call that "punted".

For this one, config.mak.dev patch WOULD only affect developer
builds, which is a much better solution than overriding what their
system headers want to do and force compiling with C99 mode.  With
the status quo with today's code, with or without the patch Dscho
wants in this thread, means ANYBODY will be stopped when they
attempt to build with -std=gnu99 on FreeBSD, which is a GOOD thing.

The reason why it is a much better solution to PUNT on using C99
mode on FreeBSD is because this episode makes it very clear that
nobody tested building anything that use basename(), dirname(),
etc. with C99 mode on the platform.  I do not trust such a build,
even if we could work around the system header breakage.

This time we got lucky and wereq stopped by a compilation error, but
I have a strong suspicion that C99-only mode of compiler on this
platform is not as well battle tested as their standard mode of
compilation that allows C11.  I simply do not think we want to waste
developer's time with C99-only mode on this platform which may end
up debugging the platform and not our program.  Next bug that will
hit us may not be so friendly to clearly break compilation.
Instead, the symptom may be a subtle runtime breakage that wastes
people's time.

After developers who work on FreeBSD (not Git developers who uses
FreeBSD) ships an updated system headers so that more programs, not
just us, are built and testsd with C99-only mode, perhaps it becomes
usable as a platform to catch use of language features beyond C99,
like everybody else.  But with such a clearly broken system headers,
I do not think today's FreeBSD is ready for that.  I do trust their
default settings that allows C11, a lot more than C99-only
compilation with the "their libgen is broken, so here is a user side
workaround" patch.