Re: pgsql/src/backend/parser (Makefile)
От | Thomas Lockhart |
---|---|
Тема | Re: pgsql/src/backend/parser (Makefile) |
Дата | |
Msg-id | 396FC35E.DBBFCFF5@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: pgsql/src/backend/parser (Makefile) (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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 по дате отправления: