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

Re: Makefile for parser

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Makefile for parser
Date: 2000-06-27 01:26:48
Message-ID: 395802D8.71865EC7@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-hackers
> > 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.

Any change to gram.y regenerates the local copy of parse.h and affects
other files *in that local directory* (as well as elsewhere). The
makefile *in that local directory* should be able to make the other
files *in that same directory* at the same time.

That's my point ;)

istm that the local makefile should at least reach up and over to the
other rule for building parse.h (wherever that is), so that parse.h gets
moved to the include/ area. If make is invoked from the top of the tree,
then it is a noop. If make is invoked from backend/parser/, then the
local files get rebuilt correctly.

                     - Tom

In response to

Responses

pgsql-hackers by date

Next:From: Mikheev, VadimDate: 2000-06-27 01:42:10
Subject: RE: Big 7.1 open items
Previous:From: Tom LaneDate: 2000-06-27 00:44:19
Subject: Is *that* why debugging backend startup is so hard!?

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