'make check' fails

Bruce Momjian <bruce@momjian.us> writes:

I have discovered that:
make clean; make check
fails with:

No doubt this is related to the generated-headers changes I've been
making, but I find your recipe confusing. "make clean" should not
have removed the generated headers from the previous build. I can
believe that if you started from a bare git checkout, did configure
and then immediately "make check", that would fail ... but I don't
think that worked before either. If it did it was certainly subject
to parallel-make race conditions.

Please be more explicit about what state you're starting from.

regards, tom lane

On Wed, Apr 11, 2018 at 10:59:45AM -0400, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I have discovered that:
make clean; make check
fails with:

No doubt this is related to the generated-headers changes I've been
making, but I find your recipe confusing. "make clean" should not
have removed the generated headers from the previous build. I can
believe that if you started from a bare git checkout, did configure
and then immediately "make check", that would fail ... but I don't
think that worked before either. If it did it was certainly subject
to parallel-make race conditions.

Please be more explicit about what state you're starting from.

OK, I can reproduce it with this:

make distclean; configure; make clean check

This is not supposed to work? It should be this?

make distclean; configure; make clean; make; make check

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

Tom> No doubt this is related to the generated-headers changes I've
Tom> been making, but I find your recipe confusing. "make clean" should
Tom> not have removed the generated headers from the previous build. I
Tom> can believe that if you started from a bare git checkout, did
Tom> configure and then immediately "make check", that would fail ...
Tom> but I don't think that worked before either. If it did it was
Tom> certainly subject to parallel-make race conditions.

Tom> Please be more explicit about what state you're starting from.

This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
clang 3.9.1, at commit 651cb90941:

git clean -dfx
./configure '--prefix=/home/andrew/work/pgsql/head' \
'--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \
'--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \
gmake -j4
gmake clean
gmake -j4 check

install.log shows:

relpath.c:21:10: fatal error: 'catalog/pg_tablespace_d.h' file not found
#include "catalog/pg_tablespace_d.h"
^
1 error generated.

--
Andrew (irc:RhodiumToad)

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

Tom> Please be more explicit about what state you're starting from.

This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
clang 3.9.1, at commit 651cb90941:

git clean -dfx
./configure '--prefix=/home/andrew/work/pgsql/head' \
'--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \
'--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \
gmake -j4
gmake clean
gmake -j4 check

Oh ... I forgot that "make clean" removes the symlinks in
src/include/catalog. Still, that also removes
src/include/utils/errcodes.h, so there was a parallel-make hazard
here before too.

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

regards, tom lane

Tom Lane wrote:

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

check-world certainly, but presumably that depends on check?

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

Tom> Please be more explicit about what state you're starting from.

This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
clang 3.9.1, at commit 651cb90941:

git clean -dfx
./configure '--prefix=/home/andrew/work/pgsql/head' \
'--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \
'--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \
gmake -j4
gmake clean
gmake -j4 check

Oh ... I forgot that "make clean" removes the symlinks in
src/include/catalog. Still, that also removes
src/include/utils/errcodes.h, so there was a parallel-make hazard
here before too.

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

In case it wasn't clear, I can reproduce this failure without parallel
mode. FYI, the reason I used this shortcut is so I can just run one
command and check one error code to know if they all worked; see
src/tools/pgtest for an example.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Tom Lane wrote:

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

check-world certainly, but presumably that depends on check?

world is OK because that already depends on "all" at the top level.
(The reason "check" is failing is basically that the "check: all"
dependencies only appear below the top level, and the MAKELEVEL
hack prevents submake-generated-headers from doing anything in
recursive child makes.)

regards, tom lane

Bruce Momjian <bruce@momjian.us> writes:

On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

In case it wasn't clear, I can reproduce this failure without parallel
mode. FYI, the reason I used this shortcut is so I can just run one
command and check one error code to know if they all worked; see
src/tools/pgtest for an example.

Probably, you got out of the habit of using parallel mode because it
fell over from time to time. The way things were done before, there
were race conditions in this usage, due to different subdirectories
independently trying to update the same generated headers.

Will commit a fix in a bit.

regards, tom lane

On Wed, Apr 11, 2018 at 01:04:56PM -0400, Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:

We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.

In case it wasn't clear, I can reproduce this failure without parallel
mode. FYI, the reason I used this shortcut is so I can just run one
command and check one error code to know if they all worked; see
src/tools/pgtest for an example.

Probably, you got out of the habit of using parallel mode because it
fell over from time to time. The way things were done before, there
independently trying to update the same generated headers.

I do use parallel make but was testing without it just in case.

Will commit a fix in a bit.

I can confirm the fix. Thanks.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +