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>
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 17:27:56
Message-ID: 20231.1005499676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Stephan Szabo 2001-11-11 18:54:05 Triggered Data Change check
Previous Message Peter Eisentraut 2001-11-11 15:40:38 Re: Patch for Makefile race against current cvs