Re: submake-errcodes
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Devrim Gündüz <devrim@gunduz.org>, Christoph Berg <myon@debian.org>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-12T14:36:08Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > But this does not work: > ./configure blah > cd src/pl/plpython/ > make -j 4 check Hm. That shows yet another parallel-safety hazard, which can be resolved like this: diff --git a/src/pl/plpython/Makefile b/src/pl/plpython/Makefile index 653fe64..c17015b 100644 --- a/src/pl/plpython/Makefile +++ b/src/pl/plpython/Makefile @@ -131,7 +131,7 @@ installcheck: submake-pg-regress .PHONY: submake-pg-regress -submake-pg-regress: +submake-pg-regress: | submake-generated-headers $(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X) clean distclean: clean-lib to ensure that we finish the generated-headers work before launching that child Make run. I'm beginning to get dissatisfied with this approach of expecting the topmost Make run to do the generated-headers work; it's bleeding into more places than I'd hoped. I don't see any really good alternative though. If we allow the child runs to try to do it, we're going to have issues with parallel runs clobbering each others' output. It's somewhat surprising that that didn't occur more often before; the only real difference since the bootstrap data restructuring is that we have more generated headers than we used to. I guess the good news is that the supported cases will be a whole lot more bulletproof against high -j counts than they were before. I never used to dare going beyond -j8, because builds tended to fall over. regards, tom lane
Commits
-
Fix YA parallel-make hazard, this one in "make check" in plpython.
- 3e110a373b81 11.0 landed
-
Put back parallel-safety guards in plpython and src/test/regress/.
- 31f1f0bb4fd6 11.0 landed
-
Fix partial-build problems introduced by having more generated headers.
- 3b8f6e75f3c8 11.0 cited