Re: meson and check-tests - Mailing list pgsql-hackers
From | jian he |
---|---|
Subject | Re: meson and check-tests |
Date | |
Msg-id | CACJufxGK6WSMR1i7E0Uw_QCs7aL6mSJ1xmu5n5Y1ekHKc+87Rg@mail.gmail.com Whole thread Raw |
In response to | Re: meson and check-tests (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
List | pgsql-hackers |
On Wed, Jun 5, 2024 at 7:26 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > > > On Mon, Jun 3, 2024 at 10:04 PM Tristan Partin <tristan@partin.io> wrote: >> >> On Sun Jun 2, 2024 at 12:25 AM CDT, Tom Lane wrote: >> > "Tristan Partin" <tristan@partin.io> writes: >> > > On Fri May 31, 2024 at 12:02 PM CDT, Ashutosh Bapat wrote: >> > >> We talked this off-list at the conference. It seems we have to somehow >> > >> avoid passing pg_regress --schedule argument and instead pass the list of >> > >> tests. Any idea how to do that? >> > >> > > I think there are 2 solutions to this. >> > > 1. Avoid passing --schedule by default, which doesn't sound like a great >> > > solution. >> > > 2. Teach pg_regress to ignore the --schedule option if specific tests >> > > are passed instead. >> > > 3. Add a --no-schedule option to pg_regress which would override the >> > > previously added --schedule option. >> > > I personally prefer 2 or 3. > > > > >> >> > >> > Just to refresh peoples' memory of what the Makefiles do: >> > src/test/regress/GNUmakefile has >> > >> > check: all >> > $(pg_regress_check) $(REGRESS_OPTS) --schedule=$(srcdir)/parallel_schedule $(MAXCONNOPT) $(EXTRA_TESTS) >> > >> > check-tests: all | temp-install >> > $(pg_regress_check) $(REGRESS_OPTS) $(MAXCONNOPT) $(TESTS) $(EXTRA_TESTS) >> >> > >> > (and parallel cases for installcheck etc). AFAICS, meson.build has >> > no equivalent to the EXTRA_TESTS add-on, nor does it have behavior >> > equivalent to check-tests' substitution of $(TESTS) for --schedule. >> > But I suggest that those behaviors have stood for a long time and >> > so the appropriate thing to do is duplicate them as best we can, >> > not invent something different. >> >> In theory, this makes sense. In practice, this is hard to emulate. We >> could make the check-tests a Meson run_target() instead of another >> test(), which would end up running the same tests more than once. > > > meson has changed the way we run individual perl tests and that looks better. So I am fine if meson provides a better wayto do what `make check-tests` does. But changing pg_regress seems a wrong choice or even making changes to the currentmake system. Instead we should make meson pass the right arguments to pg_regress. In this case, it should not pass--schedule when we need `make check-tests` like functionality. > > Just adding check-tests as new target won't help we need some way to specify "which tests" to run. Thus by default thistarget should not run any tests? I don't understand meson well. So I might be completely wrong? > > How about the following options? > 1. TESTS="..." meson test --suite regress - would run the specified tests from regress > > 2. Make `meson test --suite regress / regress/partition_join` run partition_join.sql test. I am not how to specify multipletests in this command. May be `meson test --suite regress / regress/test_setup,partition_join` will do that. makecheck-tests allows one to run multiple tests like TESTS="test_setup partition_join" make check-tests. > hi. I think it's a good feature for development. The full regression test is still a very long time to run. sometimes when you implement a feature, you are pretty sure some changes will only happen in a single sql file. so this can make it more faster.
pgsql-hackers by date: