Re: submake-errcodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Devrim Gündüz <devrim(at)gunduz(dot)org>, Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: submake-errcodes
Date: 2018-04-12 14:36:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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-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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2018-04-12 14:50:46 Re: Creation of wiki page for open items of v11
Previous Message Teodor Sigaev 2018-04-12 14:27:20 Re: Partitioned tables and covering indexes