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.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
