Michael Paquier <mich...@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
