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

It seems like VPATH building is broken at the moment, at least if you
are working from a maintainer-clean source tree.

make -C bootstrap all
make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
/usr/local/bin/bison  -o bootparse.c /home/postgres/pgsql/src/backend/bootstrap/bootparse.y
/usr/local/bin/flex  -o'bootscanner.c' /home/postgres/pgsql/src/backend/bootstrap/bootscanner.l
gcc -O1 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g -I/home/postgres/pgsql/src/backend/bootstrap
-I../../../src/include-I/home/postgres/pgsql/src/include -D_XOPEN_SOURCE_EXTENDED   -c -o bootparse.o bootparse.c
 
/home/postgres/pgsql/src/backend/bootstrap/bootparse.y:401: bootscanner.c: No such file or directory
make[3]: *** [bootparse.o] Error 1

I thought the current plan was that derived files should be generated in
the build tree (as indeed it seems to be doing) ... but there are
apparently parts of the Makefiles that are not in sync with this plan.
Has this just not been tested recently, or am I confused?
        regards, tom lane

On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
> It seems like VPATH building is broken at the moment, at least if you
> are working from a maintainer-clean source tree.
> 
> make -C bootstrap all
> make[3]: Entering directory `/home/postgres/build/src/backend/bootstrap'
> /usr/local/bin/bison  -o bootparse.c /home/postgres/pgsql/src/backend/bootstrap/bootparse.y
> /usr/local/bin/flex  -o'bootscanner.c' /home/postgres/pgsql/src/backend/bootstrap/bootscanner.l
> gcc -O1 -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -g
-I/home/postgres/pgsql/src/backend/bootstrap-I../../../src/include -I/home/postgres/pgsql/src/include
-D_XOPEN_SOURCE_EXTENDED  -c -o bootparse.o bootparse.c
 
> /home/postgres/pgsql/src/backend/bootstrap/bootparse.y:401: bootscanner.c: No such file or directory
> make[3]: *** [bootparse.o] Error 1
> 
> I thought the current plan was that derived files should be generated in
> the build tree (as indeed it seems to be doing) ... but there are
> apparently parts of the Makefiles that are not in sync with this plan.
> Has this just not been tested recently, or am I confused?

This should in principle work.  My guess is an old make version being
confused.

Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2010-01-04 at 18:49 -0500, Tom Lane wrote:
>> I thought the current plan was that derived files should be generated in
>> the build tree (as indeed it seems to be doing) ... but there are
>> apparently parts of the Makefiles that are not in sync with this plan.
>> Has this just not been tested recently, or am I confused?

> 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.
        regards, tom lane

I wrote:
> Peter Eisentraut <peter_e@gmx.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