From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: Latest LLVM breaks our code again |
Date: | 2022-02-03 19:12:00 |
Message-ID: | 20220203191200.wseonicmffxx72ns@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-02-03 10:44:11 +0100, Fabien COELHO wrote:
> > I'm doubtful that tracking development branches of LLVM is a good
> > investment. Their development model is to do changes in-tree much more than we
> > do. Adjusting to API changes the moment they're made will often end up with
> > further changes to the same / related lines. Once they open the relevant
> > release-NN branch, it's a different story.
> >
> > Maybe it'd make sense to disable --with-llvm on seawasp>
> > and have ppppppa separate animal that tracks the newest release branch?
>
> The point of seawasp is somehow to have an early warning of upcoming
> changes, especially the --with-llvm part. LLVM indeed is a moving target,
> but they very rarely back down on their API changes…
The point is less backing down, but making iterative changes that require
changing the same lines repeatedly...
> About tracking releases: this means more setups and runs and updates, and as
> I think they do care about compatibility *within* a release we would not see
> breakages so it would not be very useful, and we would only get the actual
> breakages at LLVM release time, which may be much later.
LLVM's release branches are created well before the release. E.g 13 was afaics
branched off 2021-07-27 [1], released 2021-09-30 [2].
> For these reasons, I'm inclined to let seawasp as it is.
I find seawasp tracking the development trunk compilers useful. Just not for
--with-llvm. The latter imo *reduces* seawasp's, because once there's an API
change we can't see whether there's e.g. a compiler codegen issue leading to
crashes or whatnot.
What I was proposing was to remove --with-llvm from seawasp, and have a
separate animal tracking the newest llvm release branch (I can run/host that
if needed).
Greetings,
Andres Freund
[1] git show $(git merge-base origin/release/13.x origin/main)
[2] git show llvmorg-13.0.0
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-02-03 19:16:00 | Re: Support for NSS as a libpq TLS backend |
Previous Message | Robert Haas | 2022-02-03 19:11:18 | Re: archive modules |