Re: What's the current theory about derived files in VPATH builds?

I wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> This should in principle work. My guess is an old make version being
>> confused.

> Well, I am testing with relatively old make and gcc too, but what it
> looks like to me is that we need to add a "-I." switch in places where we
> might need to #include a file out of the current build directory.

Hm, it does seem to work as expected on a Fedora 11 box. I suspect what
is happening is that gcc's rule for searching for #include's has changed
slightly since the old gcc version I have on my HPUX box. The situation
is that we are trying to #include bootscanner.c from bootparse.c, where
both of those files are in the current directory, but "." is *not* named
anywhere in the -I options. In principle the #include ought to fail,
but gcc has a special exception that causes it to look "in the directory
of the current input file" for #include files. As can be seen from the
error message, my older gcc seems to think that the "current input file"
is /home/postgres/pgsql/src/backend/bootstrap/bootparse.y --- that is,
it's probably believing the # directives rather than the originally
opened file name.

The same thing is happening in parser/gram.c, and probably in the other
places where we #include flex output from bison output.

This might be considered a gcc bug, but since we don't know when the
behavior changed, or whether other compilers have any such exception at
all, I think we ought to accommodate both ways --- ie add "-I." in the
Makefiles that require this case to work.

regards, tom lane