I discovered a problem today while trying to do a VPATH build on
a machine I don't use that often:
$ make
...
In file included from /home/tgl/pgsql/src/include/postgres.h:47,
from /home/tgl/pgsql/src/common/hashfn.c:24:
/home/tgl/pgsql/src/include/utils/elog.h:71:10: fatal error: utils/errcodes.h: No such file or directory
71 | #include "utils/errcodes.h"
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
The proximate problem is that src/include/utils/errcodes.h exists
in the VPATH build directory, but it's a symlink pointing to
src/backend/utils/errcodes.h in the build directory, which does not exist.
After a bit of looking around, I think that the cause of that is this
rule in src/backend/utils/Makefile:
$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h
prereqdir=`cd '$(dir $<)' >/dev/null && pwd` && \
cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h; do \
rm -f $$file && $(LN_S) "$$prereqdir/$$file" . ; \
done
touch $@
The last build I did on this machine was a non-VPATH build a few
weeks ago. "make distclean" from that left behind an errcodes.h
that's still up to date, so make figured it didn't have to do
anything, and the referent of the "errcodes.h" dependency here is
the errcodes.h in the source directory. On the other hand,
pg_proc.dat changed recently, so fmgr-stamp and related files
were considered out of date and rebuilt --- in the build tree.
Thus, the "prereqdir" in the above rule ends up pointing at
src/backend/utils in the build tree, but while fmgroids.h and
fmgrprotos.h do exist there, errcodes.h does not.
There are a couple different ways we might think about fixing
this. Maybe this specific rule is broken and needs to be fixed to
not assume that '$(dir $<)' is the same for all its dependencies.
Alternatively, maybe the problem is that the derived files
fmgr-stamp et al. should have been created in the source tree, even
during a VPATH build. (I have a vague recollection that we do it
that way for some derived files, but maybe that's out of date.)
Of course, it might also be fair to argue that this scenario of
a source tree that has only some up-to-date derived files is
not supported/supportable. It definitely doesn't seem worth
a huge amount of effort to fix; but on the other hand the rule
I cite above does seem to be assuming something it shouldn't.
Thoughts?
regards, tom lane
