Re: Patch for Makefile race against current cvs

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-11 15:40:38
Message-ID: Pine.LNX.4.30.0111111516100.647-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane writes:

> What bothers me is that you seem to be saying that *any* construct
> involving multiple outputs from one rule is unsafe in a parallel make.
> That strikes me as a huge restriction, and one that would surely be
> mentioned prominently in the gmake manual if it were real. But I can't
> find anything that says that.

I think we have been victims of a misunderstanding of how multiple-target
rules work. The gmake manual says:

"A rule with multiple targets is equivalent to writing many rules, each
with one target, and all identical aside from that."

So when we write this:

| $(srcdir)/preproc.c $(srcdir)/preproc.h: preproc.y
| $(YACC) -d $(YFLAGS) $<
| mv y.tab.c $(srcdir)/preproc.c
| mv y.tab.h $(srcdir)/preproc.h

make reads it as this:

| $(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: preproc.y
| $(YACC) -d $(YFLAGS) $<
| mv y.tab.c $(srcdir)/preproc.c
| mv y.tab.h $(srcdir)/preproc.h

So it's completely conceivable that both rules get executed in parallel.
(In general, you cannot optimize this away, because the actual commands
may differ depending on the value of $(at)(dot))

This basically means that you cannot correctly write a target that
generates more than one file. The only workaround I see is to cheat about
the dependencies, as Klaus' patch does:

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

It's the latter rule where we're technically cheating and which I was
initially regarding as part of the "details I don't like", but now I think
it's the best (only?) way to go.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2001-11-11 17:27:56 Re: Patch for Makefile race against current cvs
Previous Message Brent Verner 2001-11-11 09:18:44 ALTER TABLE fixes (take two)