Bjorn Munch reported off-list that this sequence:

unpack tarball, cd into it
./configure ...
cd src/test/regress

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 (
To make changes to your subscription:

Reply via email to