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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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/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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-06-27 18:07:34 RE: Big 7.1 open items
Previous Message Mikheev, Vadim 2000-06-27 17:54:55 RE: Big 7.1 open items