| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: List TAP test files in makefiles |
| Date: | 2025-12-03 10:54:39 |
| Message-ID: | f229f0a9-0aef-4b2e-b076-74358f91d10d@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01.09.25 07:09, Peter Eisentraut wrote:
> 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.
It looks like there is no consensus to go into this direction, and none
of the discussed alternatives are taking on a concrete shape, so I'm
withdrawing this patch.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2025-12-03 10:56:33 | Re: Cleanup shadows variable warnings, round 1 |
| Previous Message | Maxim Orlov | 2025-12-03 10:50:59 | Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION |