Re: Weird corner-case failure mode for VPATH builds

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Weird corner-case failure mode for VPATH builds
Date: 2020-10-13 09:48:08
Message-ID: 20201013094808.GC1856596@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2020-10-13 10:12:59 Re: partition routing layering in nodeModifyTable.c
Previous Message David Rowley 2020-10-13 09:10:15 Re: Assertion failure with LEFT JOINs among >500 relations