On 27.02.24 14:25, Alvaro Herrera wrote:
> I like this idea and I think we should integrate it with the objective
> of it becoming the workhorse of ABI-stability testing. However, I do
> not think that the subsequent patches should be part of the tree at all;
> certainly not the produced .xml files in your 0004, as that would be far
> too unstable and would cause a lot of pointless churn.
Looking at this again, if we don't want the .xml files in the tree, then
we don't really need this patch series. Most of the delicate work in
the 0001 patch was to find the right abidw options combinations to
reduce the variability in the .xml output files (--no-show-locs is an
obvious example). If we don't want to record the .xml files in the
tree, then we don't need all these complications.
For example, if we want to check the postgres backend ABI across minor
versions, we could just compile it multiple times and compare the
binaries directly:
git checkout REL_16_0
meson setup build-0
meson compile -C build-0
git checkout REL_16_STABLE
meson setup build-1
meson compile -C build-1
abidiff --no-added-syms build-0/src/backend/postgres
build-1/src/backend/postgres
> The way I see this working, is that we set up a buildfarm animal [per
> architecture] that runs the new rules produced by the abidw option and
> stores the result locally, so that for stable branches it can turn red
> when an ABI-breaking change with the previous minor release of the same
> branch is introduced. There's no point on it ever turning red in the
> master branch, since we're obviously not concerned with ABI changes there.
Maybe the way forward here is to write a buildfarm module for this, and
then see from there what further needs there are.