Re: submake-errcodes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: submake-errcodes
Дата
Msg-id 24426.1523387062@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: submake-errcodes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: submake-errcodes  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: submake-errcodes  (Christoph Berg <myon@debian.org>)
Список pgsql-hackers
I wrote:
> Hm ... you're cd'ing into src/pl/plpython and issuing "make all"?
> That works for me.
> ... or, wait ... with -j it doesn't.  That's strange, will look.

So after a bit of digging, it seems that the locution

all: submake-generated-headers

doesn't result in ensuring that submake-generated-headers is complete
before we go to build the other targets required by "all"; it only
says that submake-generated-headers must be complete before we execute
the (empty) list of commands attached to the "all" target.

I'd tested high-j runs pretty carefully at top level, but it turns
out that that works because in both the toplevel GNUmakefile and
src/Makefile, all the interesting work happens in recursive sub-makes,
and we force the ordering of those properly with the dependencies on
the recursive make rules:

$(1)-$(2)-recurse: $(if $(filter all install, $(3)), submake-generated-headers) $(if $(filter check, $(3)),
temp-install)
    $$(MAKE) -C $(2) $(3)

If you go to, eg, src/pl/plpython and issue "make -j", there's nothing
to prevent the builds of object files from happening before the header
build finishes.  There *was* something there before:

$(OBJS): | submake-generated-headers

but I took it out thinking it was no longer needed.

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.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Reopen logfile on SIGHUP