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

Re: Makefile for parser

From: Chris Bitmead <chris(at)bitmead(dot)com>
To: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Makefile for parser
Date: 2000-07-01 03:20:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On the topic of make, have you all read "Recursive Make Considered
Harmful" at

He makes a good point that most people write makefiles wrong. Certainly
the pgsql makefiles are broken for parallel make.

Chris Bitmead
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/ (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: Chris BitmeadDate: 2000-07-01 03:59:26
Subject: Re: Big 7.1 open items
Previous:From: Philip WarnerDate: 2000-06-30 23:52:57
Subject: Re: Modified pg_dump & new pg_restore need testing...

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