Re: Guiding principle for dropping LLVM versions? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Guiding principle for dropping LLVM versions?
Date
Msg-id CA+hUKGLObjcUnGPD4-=TcE2AcqESBeg1zicbhDpKjAFB1pXuGw@mail.gmail.com
Whole thread Raw
In response to Re: Guiding principle for dropping LLVM versions?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Guiding principle for dropping LLVM versions?
List pgsql-hackers
On Wed, Oct 25, 2023 at 7:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > 3.  We exclude OSes that don't bless an LLVM release (eg macOS running
> > an arbitrarily picked version), and animals running only to cover
> > ancient LLVM compiled from source for coverage (Andres's sid
> > menagerie).
>
> Seems generally reasonable.  Maybe rephrase 3 as "We consider only
> an OS release's default LLVM version"?  Or a bit more forgivingly,
> "... only LLVM versions available from the OS vendor"?  Also,
> what's an OS vendor?  You rejected macOS which is fine, but
> I think the packages available from MacPorts or Homebrew should
> be considered.

OK.  For me the key differences are that they are independent of OS
releases and time lines, they promptly add new releases, they have a
wide back-catalogue of the old releases and they let the user decide
which to use.  So I don't think they constrain us and it makes no
sense to try to apply 'end of support' logic to them.

https://formulae.brew.sh/formula/llvm
https://ports.macports.org/search/?q=llvm&name=on

(Frustratingly, the ancient releases of clang don't actually seem to
work on MacPorts at least on aarch64, and they tell you so when you
try to install them.)

The BSDs may be closer to macOS in that respect too, since they have
ports separate from OS releases and they offer a rolling and wide
range of LLVMs and generally default to a very new one, so I don't
think they constrain us either.  It's really Big Linux that is
drawing the lines in the sand here, though (unusually) not
RHEL-and-frenemies as they've opted for rolling to the latest in every
minor release as Devrim explained.



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: doc: a small improvement about pg_am description
Next
From: Nathan Bossart
Date:
Subject: Re: Remove dead code in pg_ctl.c