Re: Guiding principle for dropping LLVM versions?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Xing Guo <higuoxing(at)gmail(dot)com>, Devrim Gündüz <devrim(at)gunduz(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Guiding principle for dropping LLVM versions?
Date: 2023-10-25 20:51:47
Message-ID: CA+hUKGLObjcUnGPD4-=TcE2AcqESBeg1zicbhDpKjAFB1pXuGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 25, 2023 at 7:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-10-25 21:30:33 Re: Remove dead code in pg_ctl.c
Previous Message Jeff Davis 2023-10-25 20:45:33 Re: doc: a small improvement about pg_am description