Re: submake-errcodes

Christoph Berg <myon@debian.org>

From: Christoph Berg <myon@debian.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Devrim Gündüz <devrim@gunduz.org>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-11T08:39:54Z
Lists: pgsql-hackers
Re: Tom Lane 2018-04-10 <24426.1523387062@sss.pgh.pa.us>
> The short-term solution seems to be to put that back, but that's sort
> of annoying because it means this isn't a bulletproof solution.  It
> will only work for builds started in one of the directories that we
> take the trouble to put this defense into, and I can't see doing that
> everywhere.  Still, such things didn't work reliably before either
> except in these few directories, so maybe it won't matter.

Is that supposed to work now, without explicitly invoking sub-generated-headers?
It still doesn't work on current HEAD:

/home/cbe/projects/postgresql/pg/master/build-py3/../src/include/utils/elog.h:71:10: fatal error: utils/errcodes.h: Datei oder Verzeichnis nicht gefunden
 #include "utils/errcodes.h"
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [<eingebaut>: plpy_cursorobject.o] Fehler 1
make[2]: Verzeichnis „/home/cbe/projects/postgresql/pg/master/build-py3/src/pl/plpython“ wird verlassen

The other directories we'd need it are contrib/{hstore,jsonb,ltree}_plpython.

Christoph


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.