Re: convert libpq uri-regress tests to tap test
От | Peter Eisentraut |
---|---|
Тема | Re: convert libpq uri-regress tests to tap test |
Дата | |
Msg-id | 4f4c04c2-f23c-6668-1b24-224fc6478bfd@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: convert libpq uri-regress tests to tap test (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: convert libpq uri-regress tests to tap test
|
Список | pgsql-hackers |
On 23.02.22 23:58, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> On 23.02.22 21:30, Andres Freund wrote: >>> Where would we want that test to live? Right now we have the slightly odd >>> convention that some tap tests live in src/test/{misc,modules,...}. But >>> e.g. frontend binary ones are below src/bin/. > >> libpq TAP tests should be in src/interfaces/libpq/t/. > >> I think there were issues that the build farm wouldn't pick up a test >> located there, but that should be fixed rather than worked around. > > That's failing to account for the fact that a libpq test can't > really be a pure-perl TAP test; you need some C code to drive the > library. I don't agree with intermixing such code with libpq > itself, independently of any buildsystem issues (which there > might well be). Such things could be put under src/interfaces/libpq/test, or some other subdirectory. We already have src/interfaces/ecpg/test. > So I think the design of putting such tests under > src/modules is fine. I don't get what the rationale for that would be. libpq tests are not "modules" of any kind. If I'm working on libpq, I want to do make && make check inside the libpq source directory.
В списке pgsql-hackers по дате отправления: