Re: List TAP test files in makefiles - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: List TAP test files in makefiles
Date
Msg-id fe68fc5d-e281-40e4-b566-154d1daa3e27@eisentraut.org
Whole thread Raw
In response to List TAP test files in makefiles  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
On 23.08.25 08:09, Peter Eisentraut wrote:
> 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.

In the meantime, here is a new version to adapt to the addition of TAP 
tests for libpq-oauth.
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Update outdated references to SLRU ControlLock
Next
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]