Re: Patch for Makefile race against current cvs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch for Makefile race against current cvs
Дата
Msg-id 398.1005532607@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch for Makefile race against current cvs  (Tom Lane <tgl@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  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-patches
I wrote:
> 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.

Sigh, I guess my expectations are too high.  Some digging around in
gmake 3.79.1 shows that the submakes coordinate only to the extent
of limiting the *number* of simultaneous child processes, not to the
extent of determining what the children are doing.

I don't think that there is any really bulletproof way to invoke bison
under this sort of scenario: if there are multiple submakes executing
the same build rule then it's entirely likely that we'll see things like
one child installing a y.tab.h file that's been truncated and only
partially rewritten by another child.  Yes, the second child will
eventually make it good, but that's little comfort if the first child
launches compiles that fail meanwhile.

But we could provide some security for multiple children of a single
make by changing the rules to be like

$(srcdir)/parse.h: gram.y
ifdef YACC
    $(YACC) -d $(YFLAGS) $<
    mv y.tab.h $(srcdir)/parse.h
    mv y.tab.c $(srcdir)/gram.c
else
    @$(missing) bison $< $@
endif

$(srcdir)/gram.c: $(srcdir)/parse.h

Comments?

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [ODBC] MD5 support for ODBC
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Small FK patch to deal with tables without oids