Re: Very confusing installcheck behavior with PGXS - Mailing list pgsql-hackers
From | Jim Nasby |
---|---|
Subject | Re: Very confusing installcheck behavior with PGXS |
Date | |
Msg-id | 568E7829.2050805@BlueTreble.com Whole thread Raw |
In response to | Re: Very confusing installcheck behavior with PGXS (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Very confusing installcheck behavior with PGXS
|
List | pgsql-hackers |
On 1/6/16 11:54 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >>> The rule that gets executed if you do `make installcheck` with something >>> using PGXS is >>> >>> pgxs.mk: $(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) >>> >>> where $(pg_regress_installcheck) is set in Makefile.global.in to >>> >> pg_regress_installcheck = $(top_builddir)/src/test/regress/pg_regress >> --inputdir=$(srcdir) --bindir='$(bindir)' $(pg_regress_locale_flags) >> $(EXTRA_REGRESS_OPTS) >>> >>> The problem here is that in a PGXS make, srcdir is set to '.'[1], and >>> --inputdir is specified a second time in REGRESS_OPTS. Normally that works >>> OK (for some reason ignoring what's in ./sql), but if you happen to have a >>> file in your test/sql directory that matches a file in ./sql, pg_regress >>> runs the first file and not the second. > >> Stupid question time: why in the world would you have that? It doesn't seem that odd to have a test file that matches an extension file... > AFAICS, the pieces we supply (Makefile.global and pgxs.mk) would only > specify --inputdir once. If there's a second specification being added > to REGRESS_OPTS by your own Makefile, that would override the default, > which seems like entirely sensible behavior. Maybe I'm misunderstanding > something, but it sounds like you're saying "if I write --inputdir=test > in REGRESS_OPTS, it runs the tests in test/sql not those in ./sql". > Why would you not think that's expected? Actually, it's more bizarre than I thought... This is what my makefile[1] produces, which currently works: /Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --inputdir=./ --bindir='/Users/decibel/pgsql/HEAD/i/bin' --inputdir=test --load-language=plpgsql --dbname=contrib_regression acl_type build compat rights Removing the first --inputdir also works: /Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --bindir='/Users/decibel/pgsql/HEAD/i/bin' --inputdir=test --load-language=plpgsql --dbname=contrib_regression acl_type build compat rights However, if I do this: mv test/sql/acl_type.sql test/sql/acl.sql mv test/expected/acl_type.out test/expected/acl.out And change acl_type to acl in that pg_regress command: /Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress --bindir='/Users/decibel/pgsql/HEAD/i/bin' --inputdir=test --load-language=plpgsql --dbname=contrib_regression acl build compat rights Instead of executing test/sql/acl.sql, it executes ./sql/acl.sql. I'd assumed this was due to the extra --inputdir option, but clearly something else is going on here. Time to gvim pg_regress.c... [1] https://github.com/decibel/pg_acl -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
pgsql-hackers by date: