Re: Makefile for parser - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Makefile for parser
Date
Msg-id Pine.LNX.4.21.0006271615490.7809-100000@localhost.localdomain
Whole thread Raw
In response to Re: Makefile for parser  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: AW: Proposal: More flexible backup/restore via pg_dump
Next
From: Peter Eisentraut
Date:
Subject: RE: Big 7.1 open items