Re: Patch for Makefile race against current cvs
От | Tom Lane |
---|---|
Тема | Re: Patch for Makefile race against current cvs |
Дата | |
Msg-id | 20231.1005499676@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for Makefile race against current cvs (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Patch for Makefile race against current cvs
Re: Patch for Makefile race against current cvs |
Список | pgsql-patches |
Peter Eisentraut <peter_e@gmx.net> writes: > y.tab.c: preproc.y > $(YACC) -d $(YFLAGS) $< > $(srcdir)/preproc.c: y.tab.c > mv y.tab.c $(srcdir)/preproc.c > $(srcdir)/preproc.h: y.tab.c > mv y.tab.h $(srcdir)/preproc.h If you're going to do that, hadn't those last two better be "cp" not "mv"? What I find particularly distressing about this is that it will mean that y.tab.c and y.tab.h have to become part of the shipped distribution tarball. That's way ugly. I'd personally sooner document the existing restriction: don't use parallel make on CVS sources. As long as cheating is the order of the day, have you thought about | $(srcdir)/preproc.c: preproc.y | $(YACC) -d $(YFLAGS) $< | mv y.tab.c $(srcdir)/preproc.c | mv y.tab.h $(srcdir)/preproc.h | | $(srcdir)/preproc.h: $(srcdir)/preproc.c Also, I'm still feeling that we are missing something fundamental about parallel make. Surely there's got to be *some* interlock in make that prevents multiple subjobs from executing the same rule in parallel. Otherwise there are just too many things that are risky. I'm not even convinced that "cp tmpfile targetfile" is totally safe under such conditions. regards, tom lane
В списке pgsql-patches по дате отправления: