Re: pgsql/src/backend/parser (Makefile) - Mailing list pgsql-committers

From Thomas Lockhart
Subject Re: pgsql/src/backend/parser (Makefile)
Date
Msg-id 396FC35E.DBBFCFF5@alumni.caltech.edu
Whole thread Raw
In response to Re: pgsql/src/backend/parser (Makefile)  (Peter Eisentraut <peter_e@gmx.net>)
List 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

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql/src/backend/utils/mmgr (README)
Next
From: Bruce Momjian - CVS
Date:
Subject: pgsql/src/backend/commands (command.c)