Re: Patch for Makefile race against current cvs

On Fri, 9 Nov 2001, Tom Lane wrote:

> Klaus Naumann <knaumann@gmx-ag.de> writes:
> > To me it looks like make is calling the target twice as there are
> > two dependent files.
> > I think this is due to a dependency of a dependency.
> > Lemme explain: What I think is, that we enter a directory and make
> > a parallel build. We want to compile prepare.c , so make calls the
> > rule to build prepare.c . A second make (because it's parallel)
> > sees a file which needs prepare.h, so it calls the rule.
> > At that point the rule is called twice. If it's now doing things
> > which are not supposed to work in parallel (like moving away
> > a file) the build fails.
>
> Hmm.  It sounds to me like the issue is not the dual-output rule as
> such; it's that we have dependencies on one of the output files from
> elsewhere in the source tree, and so we end up with multiple sub-makes
> entering the backend/parser directory in parallel to build that header
> file, and then it's broken because the rule is not safe for parallel
> execution (quite independently of whether it has one or two output
> files).

This might be also true. But I that far to say, that this happens
within the same directory.
What I mean is, the file which generate the dependencies you are talking
about are in the same directory as the bison files.

> But that's supposed to be taken care of by having the parse.h file
> updated before we start recursing into the rest of the backend --- see
> src/backend/Makefile.  Why is that not stopping the problem?

s.a.

> Did you see any actual failures related to the other bison invocations,
> or just the one in backend/parser?  AFAIK the other ones generate files
> that are only used within their one source directory, and so they should
> not have this problem anyway.  There should only be one sub-make looking
> at the other ones.

Yes, I also have seen races in two other directories
(and decided to change all occorences of the two-file
target in any Makefile because I'm under the impression
that it's to dangerous ...).
I have seen problems in src/backend/bootstrap and in
src/pl/plpgsql/src too.

    Bye, Klaus

--
Klaus Naumann
Systems Administration
GMX  Aktiengesellschaft
Riesstrasse 17, 80992 München
Telefon +49.89.143 39-0
Telefax +49.89.143 39-100
mailto:knaumann@gmx-ag.de
http://www.gmx.net/