Hello Andres,
> 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… As pg version are
expected to run for 5 years, they will encounter newer compiler versions,
so being as ready as possible seems worthwhile.
ISTM that there is no actual need to fix LLVM breakage on the spot, but I
think it is pertinent to be ok near release time. This is why there is a
"EXPERIMENTAL" marker in the system description. There can be some noise
when LLVM development version is broken, this has happened in the past
with seawasp (llvm) and moonjelly (gcc), but not often.
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.
For these reasons, I'm inclined to let seawasp as it is.
--
Fabien.