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).
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?
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.
regards, tom lane
