Re: submake-errcodes

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Devrim Gündüz <devrim@gunduz.org>
Cc: Christoph Berg <myon@debian.org>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-12T18:36:00Z
Lists: pgsql-hackers
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
> ... still same error. Easy to reproduce on F-27 box. 

I don't have F27 at hand, but I tried F26 and F28, and I can't reproduce
on either one.  I tried various combinations of python2 versus python3,
in-tree build versus VPATH from bare checkout versus VPATH from
distprep'd tree, and they all work for me.

Just to clarify, I'm experimenting with

$ git clean -dfx
$ ./configure ... --with-python [ PYTHON=/usr/bin/python3 ]
$ cd src/pl/plpython/
$ make -j25

and variants of that, and what I get as a result is a make trace
starting with

make -C ../../../src/backend generated-headers

If you're not seeing that, something's very wrong, and I do not
know what.

[ time passes ]

... or then again, maybe I do.  Is it possible that your build
recipe involves invoking our makefiles from an outer "make" run?
If so, maybe you need to explicitly set MAKELEVEL=0 when invoking
our build, to keep it from thinking it is a sub-make.  Not sure
about whether it'd be wise to reset MAKEFLAGS as well.

			regards, tom lane


Commits

  1. Fix YA parallel-make hazard, this one in "make check" in plpython.

  2. Put back parallel-safety guards in plpython and src/test/regress/.

  3. Fix partial-build problems introduced by having more generated headers.