Re: List TAP test files in makefiles
| От | Peter Eisentraut |
|---|---|
| Тема | Re: List TAP test files in makefiles |
| Дата | |
| Msg-id | f229f0a9-0aef-4b2e-b076-74358f91d10d@eisentraut.org обсуждение исходный текст |
| Ответ на | Re: List TAP test files in makefiles (Peter Eisentraut <peter@eisentraut.org>) |
| Список | 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.
В списке pgsql-hackers по дате отправления: