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