Skip site navigation (1) Skip section navigation (2)

Re: Makefile for parser

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Makefile for parser
Date: 2000-06-27 18:05:49
Message-ID: Pine.LNX.4.21.0006271615490.7809-100000@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: 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/ (perhaps as a wrapper around 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            Sweden

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-06-27 18:07:34
Subject: RE: Big 7.1 open items
Previous:From: Mikheev, VadimDate: 2000-06-27 17:54:55
Subject: RE: Big 7.1 open items

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group