Support "make check" for PGXS extensions
This is a quick follow-up to the extension_control_path patch. With
this little additional patch, you can now run "make check" in PGXS-using
extensions (instead of having to do make install; make installcheck with
a running instance). I think this would be very convenient for
extension development.
The patch is still rough, probably needs a bit of work to do proper
escaping, quoting, further testing, and it will probably break if you
use a different source tree layout. Maybe with a bit of help we can get
this robust enough. Or otherwise, it can at least serve as inspiration
for what you can implement yourself in your extension's makefile.
Attachments:
v0-0001-WIP-Support-make-check-for-PGXS-extensions.patchtext/plain; charset=UTF-8; name=v0-0001-WIP-Support-make-check-for-PGXS-extensions.patchDownload
From d08218d36d4590f80c2d46f3d7c30bee3e35b7e2 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Thu, 20 Mar 2025 14:00:18 +0100
Subject: [PATCH v0] WIP: Support "make check" for PGXS extensions
---
src/Makefile.global.in | 3 +++
src/makefiles/pgxs.mk | 7 +++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 8fe9d61e82a..97a7491febb 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -396,6 +396,7 @@ endif
# In much the same way as above, these rules ensure that we build a temp
# install tree just once in any recursive "make check". The additional test
# on abs_top_builddir prevents doing anything foolish to the root directory.
+ifndef PGXS
check: temp-install
@@ -440,6 +441,8 @@ endif
checkprep:
$(if $(EXTRA_INSTALL),for extra in $(EXTRA_INSTALL); do $(MAKE) -C '$(top_builddir)'/$$extra DESTDIR='$(abs_top_builddir)'/tmp_install install || exit; done)
+endif # not PGXS
+
PROVE = @PROVE@
# There are common routines in src/test/perl, and some test suites have
# extra perl modules in their own directory.
diff --git a/src/makefiles/pgxs.mk b/src/makefiles/pgxs.mk
index 0de3737e789..9fe8e1d0cb4 100644
--- a/src/makefiles/pgxs.mk
+++ b/src/makefiles/pgxs.mk
@@ -446,8 +446,11 @@ endif # NO_INSTALLCHECK
# Runs independently of any installation
ifdef PGXS
check:
- @echo '"$(MAKE) check" is not supported.'
- @echo 'Do "$(MAKE) install", then "$(MAKE) installcheck" instead.'
+ifdef REGRESS
+ echo "dynamic_library_path = '\$$libdir:$(CURDIR)'" >>$(CURDIR)/temp.conf
+ echo "extension_control_path = '\$$system:$(CURDIR)'" >>$(CURDIR)/temp.conf
+ $(pg_regress_check) $(REGRESS_OPTS) $(REGRESS) --temp-config $(CURDIR)/temp.conf
+endif
else
check: submake $(REGRESS_PREP)
ifdef REGRESS
base-commit: 618c64ffd3967cb5313b4b11e1e1043a074f2139
--
2.49.0
On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote:
This is a quick follow-up to the extension_control_path patch. With this little additional patch, you can now run "make check" in PGXS-using extensions (instead of having to do make install; make installcheck with a running instance). I think this would be very convenient for extension development.
I LOVE this idea! But one thing to keep in mind is that not all files are in CURDIR. Might make sense to use `dirname` on all the entires in DATA and MODULES to figure out what to put in the search paths. I usually have my C files in `src` and SQL files in `sql`, and wrote the PGXN tutorial[1]https://manager.pgxn.org/howto#neworder back in 2012 with that pattern (for better or worse). A simple example is the envvar extension[2]https://github.com/theory/pg-envvar/blob/main/Makefile:
DATA = $(wildcard sql/*.sql)
MODULES = $(patsubst %.c,%,$(wildcard src/*.c))
Best,
David
[1]: https://manager.pgxn.org/howto#neworder
[2]: https://github.com/theory/pg-envvar/blob/main/Makefile
On 3/20/25 13:20, David E. Wheeler wrote:
On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote:
This is a quick follow-up to the extension_control_path patch.
With this little additional patch, you can now run "make check" in
PGXS-using extensions (instead of having to do make install; make
installcheck with a running instance). I think this would be very
convenient for extension development.
I LOVE this idea!
+many
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 2025-03-20 Th 9:06 AM, Peter Eisentraut wrote:
This is a quick follow-up to the extension_control_path patch. With
this little additional patch, you can now run "make check" in
PGXS-using extensions (instead of having to do make install; make
installcheck with a running instance). I think this would be very
convenient for extension development.The patch is still rough, probably needs a bit of work to do proper
escaping, quoting, further testing, and it will probably break if you
use a different source tree layout. Maybe with a bit of help we can
get this robust enough. Or otherwise, it can at least serve as
inspiration for what you can implement yourself in your extension's
makefile.
No support for TAP tests, AFAICT. I guess this is a first step, but TAP
support would be nice.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Thu, Mar 20, 2025 at 1:57 PM Joe Conway <mail@joeconway.com> wrote:
I LOVE this idea!
+many
Same here. But I also agree with Andrew that it would be fantastic if
TAP tests could be made to work, too. Yet, anything beats nothing!
--
Robert Haas
EDB: http://www.enterprisedb.com
On 20.03.25 18:20, David E. Wheeler wrote:
On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote:
This is a quick follow-up to the extension_control_path patch. With this little additional patch, you can now run "make check" in PGXS-using extensions (instead of having to do make install; make installcheck with a running instance). I think this would be very convenient for extension development.
I LOVE this idea! But one thing to keep in mind is that not all files are in CURDIR. Might make sense to use `dirname` on all the entires in DATA and MODULES to figure out what to put in the search paths. I usually have my C files in `src` and SQL files in `sql`, and wrote the PGXN tutorial[1] back in 2012 with that pattern (for better or worse). A simple example is the envvar extension[2]:
DATA = $(wildcard sql/*.sql)
MODULES = $(patsubst %.c,%,$(wildcard src/*.c))
Interesting. I think to support that, we would need to do a temp
install kind of thing of the extension, and then point the path settings
into that temp install directory. Which is probably more sensible anyway.
On Mar 27, 2025, at 12:21, Peter Eisentraut <peter@eisentraut.org> wrote:
Interesting. I think to support that, we would need to do a temp install kind of thing of the extension, and then point the path settings into that temp install directory. Which is probably more sensible anyway.
If it runs against a temporary cluster anyway, I think that makes perfect sense.
D