From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support "make check" for PGXS extensions |
Date: | 2025-03-27 16:21:47 |
Message-ID: | 8ba74444-9bda-4c9c-a1d2-32b365b331a0@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20.03.25 18:20, David E. Wheeler wrote:
> On Mar 20, 2025, at 09:06, Peter Eisentraut <peter(at)eisentraut(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2025-03-27 16:31:37 | Re: Test to dump and restore objects left behind by regression |
Previous Message | Tomas Vondra | 2025-03-27 16:14:00 | Re: Amcheck verification of GiST and GIN |