Re: Patch for Makefile race against current cvs
От | Tom Lane |
---|---|
Тема | Re: Patch for Makefile race against current cvs |
Дата | |
Msg-id | 21622.1005337230@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for Makefile race against current cvs (Klaus Naumann <knaumann@gmx-ag.de>) |
Ответы |
Re: Patch for Makefile race against current cvs
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: