On the topic of make, have you all read "Recursive Make Considered
Harmful" at http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html
He makes a good point that most people write makefiles wrong. Certainly
the pgsql makefiles are broken for parallel make.
Peter Eisentraut wrote:
> Tom Lane writes:
> > > I've started doing a bit of work on gram.y, and am noticing some new
> > > cruftiness in the Makefile: if I add tokens to gram.y/keywords.c then I
> > > can't just remake in that directory since parse.h is not updated
> > > elsewhere in the tree.
> > Uh ... what's your point? If the changes to parse.h affect anything
> > else then you ought to be doing a top-level make --- or at the very
> > least a make in src/backend --- and that will rebuild
> > include/parser/parse.h.
> I'm having a feeling that this will not work too well with parallel
> make. Every directory needs to know how to make all the files that it
> needs. For the case of parse.h it would not be too difficult to teach the
> few places that need it:
> src/backend$ find -name '*.c' | xargs fgrep 'parse.h' | fgrep -v './parser/'
> ./commands/command.c:#include "parser/parse.h"
> ./commands/comment.c:#include "parser/parse.h"
> ./nodes/outfuncs.c:#include "parser/parse.h"
> ./tcop/utility.c:#include "parser/parse.h"
> fmgroids.h on the other hand would be trickier. We might need a
> backend/Makefile.inc (perhaps as a wrapper around Makefile.global) to do
> it right. But I haven't gotten to the backend tree at all yet.
> Peter Eisentraut Sernanders väg 10:115
> peter_e(at)gmx(dot)net 75262 Uppsala
> http://yi.org/peter-e/ Sweden
In response to
pgsql-hackers by date
|Next:||From: Chris Bitmead||Date: 2000-07-01 03:59:26|
|Subject: Re: Big 7.1 open items|
|Previous:||From: Philip Warner||Date: 2000-06-30 23:52:57|
|Subject: Re: Modified pg_dump & new pg_restore need testing...|