Re: Makefile for parser

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