Re: [PATCH v2] config.mak.uname: update settings for FreeBSD

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2025, 16:52 UTC
Message-ID: <xmqqy0twewc6.fsf@gitster.g>
In-Reply-To: <CAPUEspguEY+e-J0dMA2EdDgu=t4fK5ASS13Jfp_Mgwiq3Rtd0Q@mail.gmail.com>

Carlo Arenas <carenas@gmail.com> writes:

Show 6 quoted lines

> On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
>>
>> FreeBSD 6.0 has memmem().
>
> but AFAIK it was buggy, uncompatible with the "standard" and
> didn't perform that well, at least until FreeBSD 12.

Declaring that we will not support anything older than 12, which was from Dec 2018, feels a bit too harsh, so conditional to check if we are at or above 12 is needed instead?

Documentation/technical/platform-support.adoc is probably a good place to start a discussion.

 * It spells out Minimum Requirements which includes C99 at the
   minimum, which in turn disqualifies really ancient ones and ones
   perhaps before FreeBSD 7 (which had GCC 4)?

 * It also requires the platform has active security support.  If I
   trust https://www.freebsd.org/security/#sup page, it means
   anything older than 13.4-RELEASE are EoL already.

 * The document has a space at the end that is intended to list
   contacts for ports on platforms, but currently it is not very
   actively used.  Should we extend it to include various flavours
   of BSDs and other systems, and start listing the minimum
   supported versions as well?

Stepping back a bit, do we already have some mechanism to say "hey you seem to be on FreeBSD but you are at release N that is way older than the minimum version X we support" and stop the build? If we do, we should tell that mechanism about our decision in a patch like this.

If we don't, I wonder if we want to have such a mechanism? I am personally undecided. It would help those "casual" users and builders who do not get their hands dirty at all (aka "I'll build only from the official release tarballs") if we did so when they try to build on something we know will not work well, especially if it is kept up to date relative to what the platform-support document lists. But at the same time, those who do not mind fixing and extending to make it work on out-of-support systems will be inconvenienced with one more roadblock to dismantle before proceeding.

Thoughts?