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
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) |