From: Junio C Hamano <gitster@pobox.com>
To: Carlo Arenas <carenas@gmail.com>
Cc: Brad Smith <brad@comstyle.com>, git@vger.kernel.org
Subject: Re: [PATCH v2] config.mak.uname: update settings for FreeBSD
Date: Thu, 12 Jun 2025 09:52:25 -0700 [thread overview]
Message-ID: <xmqqy0twewc6.fsf@gitster.g> (raw)
In-Reply-To: <CAPUEspguEY+e-J0dMA2EdDgu=t4fK5ASS13Jfp_Mgwiq3Rtd0Q@mail.gmail.com> (Carlo Arenas's message of "Thu, 12 Jun 2025 06:52:03 -0700")
Carlo Arenas <carenas@gmail.com> writes:
> 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?
next prev parent reply other threads:[~2025-06-12 16:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 13:52 [PATCH v2] config.mak.uname: update settings for FreeBSD Carlo Arenas
2025-06-12 16:48 ` brian m. carlson
2025-06-12 21:31 ` Carlo Marcelo Arenas Belón
2025-06-12 21:51 ` [PATCH v3] " Junio C Hamano
2025-06-12 22:30 ` Carlo Marcelo Arenas Belón
2025-06-12 22:37 ` Junio C Hamano
2025-07-02 9:37 ` [PATCH v4 0/2] " Carlo Marcelo Arenas Belón
2025-07-02 9:37 ` [PATCH v4 1/2] config.mak.uname: set NO_MEMMEM only for functional version Carlo Marcelo Arenas Belón
2025-07-02 9:37 ` [PATCH v4 2/2] build: retire NO_UINTMAX_T Carlo Marcelo Arenas Belón
2025-07-02 16:21 ` [PATCH v4 0/2] config.mak.uname: update settings for FreeBSD Junio C Hamano
2025-06-12 16:52 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-06-12 4:36 [PATCH v2] " Brad Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy0twewc6.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=brad@comstyle.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).