Thread: VPATH builds fail

I experimented today (for the first time in a long time) with building
Postgres outside the source tree.  Didn't work:

make[3]: Entering directory `/home/users/t/tg/tgl/builddir/src/backend/bootstrap'
gcc -O1 -g -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../src/include
-I/home/users/t/tg/tgl/pgsql/src/include  -c -o bootparse.o
/home/users/t/tg/tgl/pgsql/src/backend/bootstrap/bootparse.c
gcc -O1 -g -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../src/include
-I/home/users/t/tg/tgl/pgsql/src/include  -c -o bootscanner.o
/home/users/t/tg/tgl/pgsql/src/backend/bootstrap/bootscanner.c
bootscanner.l:43: bootstrap_tokens.h: No such file or directory
make[3]: *** [bootscanner.o] Error 1

and similarly in src/interfaces/ecpg/preproc.

The problem was that I already had bison output files built in the
source tree.  If I remove those, the build goes through (with bison
output files built in the object tree).  However, since our source
distribution tarballs come with prebuilt bison outputs, this means
that a VPATH build from a source tarball won't work.

The simplest fix is probably to addoverride CPPFLAGS := -I$(srcdir) $(CPPFLAGS)
to the Makefiles in these two directories.  (I observe that plpgsql
already has this, which is why it fails to fail; backend/parser gets
around the same problem by installing symlinks.)  Any objections?
        regards, tom lane

I said:
> The problem was that I already had bison output files built in the
> source tree.  If I remove those, the build goes through (with bison
> output files built in the object tree).

I have to take that back: the bison outputs are rebuilt in the source
tree, as indeed they should be.  I'm now fairly confused about why
the first build attempt failed and the second succeeded.  The failure
occurred on a machine running gmake 3.78.1 ... maybe this is some
bug in that version of make?  I can't reproduce any problem on a machine
running gmake 3.79.1...
        regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:
> I can't reproduce this with either version of gmake, and the rules look
> fairly bullet-proof.  Possibly you didn't distclean the source tree before
> configuring in the build tree.

Yes, I certainly did distclean.  The difference is in the bison output
files, which are not removed by distclean; see followup message.
AFAICT it is not really make's fault, but an obscure gcc behavior that
creates the problem.
        regards, tom lane

I said:
> I have to take that back: the bison outputs are rebuilt in the source
> tree, as indeed they should be.  I'm now fairly confused about why
> the first build attempt failed and the second succeeded.

The difference appears to be that when bison is run in the source dir,
its output contains lines like
#line 121 "bootscanner.l"

However, when it's run during a VPATH build, its output contains lines
like
#line 121 "/home/postgres/pgsql/src/backend/bootstrap/bootscanner.l"

evidently because bison is invoked with a full path to the .y file in
this case.

There is *no* difference in the #include commands, but apparently the
#line directives affect gcc's default search path for include files.

Net result: I'm back to my original statement: VPATH builds will not
work with a source distribution tarball.  Any objections to the
-I$(srcdir) trick?
        regards, tom lane

Tom Lane writes:

> I have to take that back: the bison outputs are rebuilt in the source
> tree, as indeed they should be.  I'm now fairly confused about why
> the first build attempt failed and the second succeeded.  The failure
> occurred on a machine running gmake 3.78.1 ... maybe this is some
> bug in that version of make?  I can't reproduce any problem on a machine
> running gmake 3.79.1...

I can't reproduce this with either version of gmake, and the rules look
fairly bullet-proof.  Possibly you didn't distclean the source tree before
configuring in the build tree.  In that case it might have picked up the
wrong Makefile.global for part of the build.

-- 
Peter Eisentraut   peter_e@gmx.net

Tom Lane writes:

> There is *no* difference in the #include commands, but apparently the
> #line directives affect gcc's default search path for include files.

I was kind of baffled myself why it worked at all.

> Net result: I'm back to my original statement: VPATH builds will not
> work with a source distribution tarball.  Any objections to the
> -I$(srcdir) trick?

Nope.

-- 
Peter Eisentraut   peter_e@gmx.net