Re: Patch for Makefile race against current cvs - Mailing list pgsql-patches

From Tom Lane
Subject Re: Patch for Makefile race against current cvs
Date
Msg-id 398.1005532607@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch for Makefile race against current cvs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [ODBC] MD5 support for ODBC
Next
From: Bruce Momjian
Date:
Subject: Re: Small FK patch to deal with tables without oids