Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us> > Bjorn Munch reported off-list that this sequence: > > unpack tarball, cd into it > ./configure ... > cd src/test/regress > make > > no longer works in 9.6beta2, where it did work in previous releases. > I have confirmed both statements. The failure looks like > > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -Wendif-labels -Wmissing-format-attribute -Wformat-security > -fno-strict-aliasing -fwrapv -g -O1 -fpic -I../../../src/include > -D_GNU_SOURCE -c -o regress.o regress.c > In file included from ../../../src/include/storage/lock.h:23, > from ../../../src/include/access/heapam.h:22, > from ../../../src/include/nodes/execnodes.h:18, > from ../../../src/include/commands/trigger.h:17, > from regress.c:29: > ../../../src/include/storage/lwlock.h:129:33: error: storage/lwlocknames.h: > No such file or directory > make: *** [regress.o] Error 1 > > So this is some sort of fallout from commit aa65de042f582896, which > invented that as a generated file. > > Perhaps the solution is to extend src/test/regress/GNUmakefile to know > about this file explicitly (as it already does know about > src/port/pg_config_paths.h). But that seems rather brute-force; in > particular it seems like that does nothing to keep us from getting burnt > again the same way in future. I wonder if we should modify > src/backend/Makefile so that it exposes a phony target for "update all the > generated include files", and then have src/test/regress/GNUmakefile call > that. Or maybe there are other ways.
That would also fix the "build plpython3 only" problem I was aiming at in https://www.postgresql.org/message-id/20150916200959.gb32...@msg.df7cb.de So another +1 from a packagers perspective. Christoph
signature.asc
Description: PGP signature
