On Tue, Jan 18 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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/20220116020520.26895-1-davvid@xxxxxxxxx/ 2. https://lore.kernel.org/git/patch-1.1-9cea01a1395-20220117T170457Z-avarab@xxxxxxxxx/
