Thread: pgsql/src/backend/parser (Makefile)
Date: Friday, July 14, 2000 @ 11:32:04
Author: thomas
Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/parser
from hub.org:/home/projects/pgsql/developers/thomas/CURRENT/pgsql/src/backend/parser
Modified Files:
Makefile
----------------------------- Log Message -----------------------------
Include rule to build include/parser/parse.h since nothing else can
build in this directory otherwise :(
Thomas Lockhart writes: > Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/parser > from hub.org:/home/projects/pgsql/developers/thomas/CURRENT/pgsql/src/backend/parser > > Modified Files: > Makefile > Include rule to build include/parser/parse.h since nothing else can > build in this directory otherwise :( 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? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
regards, tom lane
> > 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
Tom Lane writes: > 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. Some of the files in backend/parser include fmgroids.h, so in order to build anything there you have to build the backend at least once before you start fiddling with the parser. Once you have done that there will be a symlink from backend/parser/parse.h to include/parser/parse.h, so whatever you recompile backend/parser locally the changes to parse.h get propagated automatically. The only thing this change would work around is if you do - fresh source - configure - cd src/backend/parser - make but that won't work anyway, as I mentioned. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Some of the files in backend/parser include fmgroids.h, so in order to
> build anything there you have to build the backend at least once before
> you start fiddling with the parser.
Right.
> Once you have done that there will be
> a symlink from backend/parser/parse.h to include/parser/parse.h, so
> whatever you recompile backend/parser locally the changes to parse.h get
> propagated automatically.
Was it a symlink already? I thought I recalled it being a hard link or
a copy.
There might also be a dependency issue, ie does make realize that
updating backend/parser/parse.h means it has to recompile files
that are shown as depending on include/parser/parse.h. Offhand it
seems that this will fail to work unless backend/parser/Makefile
has a rule that makes the latter dependent on the former.
regards, tom lane
Tom Lane writes:
> Was it a symlink already? I thought I recalled it being a hard link or
> a copy.
We're moving ahead fast. :)
> There might also be a dependency issue, ie does make realize that
> updating backend/parser/parse.h means it has to recompile files
> that are shown as depending on include/parser/parse.h.
It seems to be a stat() vs lstat() issue; the symlink is automatically
up-to-date because when make inspects it it will find the timestamp of the
underlying file. So the answer to your question seems to be yes.
$ ls
Makefile
$ cat Makefile
first: second
touch $@
second: third
ln -s $< $@
$ touch third
$ make
ln -s third second
touch first
$ touch third
$ make
touch first
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> There might also be a dependency issue, ie does make realize that
>> updating backend/parser/parse.h means it has to recompile files
>> that are shown as depending on include/parser/parse.h.
> It seems to be a stat() vs lstat() issue; the symlink is automatically
> up-to-date because when make inspects it it will find the timestamp of the
> underlying file. So the answer to your question seems to be yes.
Your example misses the point though, because the symlink can be seen to
be out of date when Make starts up. If make runs a rule to update
backend/parser/parse.h, will it know *in the same run* that this implies
running rules that are dependent on include/parser/parse.h, or will it
already have decided it does not have to run those rules? Seems
particularly dangerous in a parallel-make situation.
regards, tom lane