Re: Broken handling of lwlocknames.h

Re: Tom Lane 2016-06-27 <31398.1467036827@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.GB32090@msg.df7cb.de

So another +1 from a packagers perspective.

Christoph