Re: List TAP test files in makefiles

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.

In response to

Browse pgsql-hackers by date

  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