Re: Broken handling of lwlocknames.h

Re: Tom Lane 2016-06-27 <31398(dot)1467036827(at)sss(dot)pgh(dot)pa(dot)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.GB32090@msg.df7cb.de

So another +1 from a packagers perspective.

Christoph