Re: Patch for Makefile race against current cvs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Klaus Naumann <knaumann(at)gmx-ag(dot)de>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Patch for Makefile race against current cvs
Date: 2001-11-12 02:36:47
Message-ID: 398.1005532607@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Hiroshi Inoue 2001-11-12 03:06:49 Re: Triggered Data Change check
Previous Message Bruce Momjian 2001-11-12 01:49:57 Re: [ODBC] MD5 support for ODBC