Re: submake-errcodes
От | Tom Lane |
---|---|
Тема | Re: submake-errcodes |
Дата | |
Msg-id | 26222.1523543768@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: submake-errcodes (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: submake-errcodes
|
Список | 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
В списке pgsql-hackers по дате отправления: