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.
--
Chris Bitmead
mailto:chris@bitmead.com
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@gmx.net 75262 Uppsala
> http://yi.org/peter-e/ Sweden
