Broken handling of lwlocknames.h

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Broken handling of lwlocknames.h
Date: 2016-06-27 14:13:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-27 15:00:28 Re: Rethinking representation of partial-aggregate steps
Previous Message Amit Langote 2016-06-27 10:26:13 Re: Declarative partitioning