Re: pgsql/src/backend/parser (Makefile)

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Lockhart <thomas(at)hub(dot)org>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src/backend/parser (Makefile)
Date: 2000-07-15 01:50:22
Message-ID: 396FC35E.DBBFCFF5@alumni.caltech.edu
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

> > Actually, this is not quite correct because include/parser/parse.h should
> > be a symlink to, not a copy of, the original file. I don't quite
> > understand either. If you make all in the backend tree then the
> > include/parser/parse.h should always be up to date with the
> > backend/parser/parse.h version. Or do you build backend/parser before
> > *anything* else?
> No, he wants to be able to edit gram.y (changing parse.h) and other
> files (using parse.h) in parser, then do a "make" in that directory to
> see if it compiles. As things were, he had to start the make at backend
> top level just to see if the parser compiles, because there was no other
> way to get include/parser/parse.h up to date. But you might be right
> that a symlink would be a better answer.

Yup, that's the scenario. Another possibility would be to use more "-I"
arguments during compilation, then flattening the directory structure in
the #include statements. Then a "-I." would let me build locally.

afaik we rely on file copying rather than simlinks everywhere else, but
if that isn't the case then a simlink here would be just fine.

- Thomas

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian - CVS 2000-07-15 12:37:14 pgsql/src/backend/commands (command.c)
Previous Message Tom Lane 2000-07-15 00:52:22 pgsql/src/backend/utils/mmgr (README)