Обсуждение: Weird corner-case failure mode for VPATH builds
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
On Fri, Sep 4, 2020 at 9:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. I think I've seen this before, but I don't have an opinion on how to fix it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2020-Sep-11, Robert Haas wrote: > On Fri, Sep 4, 2020 at 9:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. > > I think I've seen this before, but I don't have an opinion on how to fix it. Me too. It would be useful to have a way to report that build artifacts are in the source dir that should be in the build dir. I don't know if this is in any way workable. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, On 2020-09-11 13:58:41 -0300, Alvaro Herrera wrote: > On 2020-Sep-11, Robert Haas wrote: > > > On Fri, Sep 4, 2020 at 9:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > 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. > > > > I think I've seen this before, but I don't have an opinion on how to fix it. > > Me too. It would be useful to have a way to report that build artifacts > are in the source dir that should be in the build dir. I don't know if > this is in any way workable. "git clean -nx" should list them for vpath builds. Regards, Andres
On Fri, Sep 04, 2020 at 09:49:16PM -0400, Tom Lane wrote: > 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.) The GNU make manual does recommend: GNU distributions usually contain some files which are not source files—for example, Info files, and the output from Autoconf, Automake, Bison or Flex. Since these files normally appear in the source directory, they should always appear in the source directory, not in the build directory. So Makefile rules to update them should put the updated files in the source directory. -- https://www.gnu.org/software/make/manual/html_node/Makefile-Basics.html > 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. I agree fixing this is low-priority.