Peter Eisentraut <peter_e@gmx.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