From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Devrim Gündüz <devrim(at)gunduz(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: submake-errcodes |
Date: | 2018-04-10 19:04:22 |
Message-ID: | 24426.1523387062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-10 19:17:49 | Re: Reopen logfile on SIGHUP |
Previous Message | Joshua D. Drake | 2018-04-10 18:58:37 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |