From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | List TAP test files in makefiles |
Date: | 2025-08-23 06:09:50 |
Message-ID: | 2cdd6c8b-9631-4ba4-b051-eec1168ac960@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
meson.build files have to list TAP test files explicitly. Makefiles
have been relying on a t/*.pl wildcard. As a consequence, it is
traditional now that many developers who are primarily using make forget
to add any new TAP test files to the respective meson.build file.
The obvious solution is to also require the makefiles to list TAP files
explicitly, which is what I'm proposing here.
To list the test files, I'm re-using the make variable TAP_TESTS that is
already in use by extensions. Extensions up to now would just write
something like
TAP_TESTS = 1
Starting with this patch, they would have to write
TAP_TESTS = t/001_foo.pl t/002_bar.pl
This makes it somewhat backward compatible. (For example, with the
latter formulation, PG<=18 would still read it as enabling TAP tests,
but it would ignore the actual file list.)
(I have considered other variants: We already have the make variable
PROVE_TESTS that you can use to override the list of tests from the make
command line. But if you use that one to list the tests in an extension
makefile, then that extension would have to use both PROVE_TESTS and
TAP_TESTS (to enable TAP tests overall), which seems pretty confusing.
I think the solution I ended up with is compact and intuitive.)
In the attached patch, I have arranged it so that the interesting
changes are in the first three files, the rest is just mechanical.
Attachment | Content-Type | Size |
---|---|---|
0001-List-TAP-test-files-in-makefiles.patch | text/plain | 36.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2025-08-23 06:56:12 | Re: Adding REPACK [concurrently] |
Previous Message | Noah Misch | 2025-08-23 05:20:19 | Re: Test instability when pg_dump orders by OID |