Hi Christoph,
> I've done that now, it will be available in postgresql-common 256.
Thank you!
> pg_buildext run_installed /usr/bin/cmake -Btest-%v
> pg_buildext run_installed make -C test-% test
>
> ... but that starts by recompiling the package instead of just running
> the tests.
>
> Perhaps you have an idea how to make it work? The existing
> debian/tests/regress.sh file looks very complex and might break with
> every little upstream change. (Of course if there's no easier way to
> get the upstream testsuite to run, we have to go the complex route.)
I agree with your assessment of d/tests/regress.sh. The reason I went
that route initially was because running cmake followed by make test was
rebuilding the package. I did see that autopkgtest has the
'build-needed' restriction [1] but its use seems to be discouraged. I
took another look at the upstream testsuite to see if we can (easily)
run its testsuite without require a rebuild and I think I have found a
way.
In short, upstream was defining a test called 'build' that would rebuild
the extension. We can instruct ctest to exclude this test by specifying
a regex. I was able to drop regress.sh altogether and have
d/tests/installcheck run
cmake -Btest-%v
make -C test-%v ARGS='-E build' test
This does require repeating the list of -dev packages in d/tests/control
so that cmake can generate the Makefiles. If this sounds like a good
approach to you, I can push the commit to s.d.o.
--Bradford
[1]: https://people.debian.org/~eriberto/README.package-tests.html