From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Postgres hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h
 headers.
In-reply-to: <6629.1523294509@sss.pgh.pa.us>
References: <E1f5FAB-0006LU-MB@gemulon.postgresql.org>
 <20180409010031.GA11599@paquier.xyz> <16609.1523243109@sss.pgh.pa.us>
 <20180409061354.GD1740@paquier.xyz> <6629.1523294509@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 09 Apr 2018 13:21:49 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17754.1523306794.1@sss.pgh.pa.us>
Date: Mon, 09 Apr 2018 16:46:34 -0400
Message-ID: <17755.1523306794@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> That takes care of the problem from the root of the directory, but when
>> doing the same from src/bin/ then the same issue shows up even if
>> src/Makefile is patched to handle install targets.

> Hm.  Not sure how far we want to go in that direction.  It's never really
> been the case that you could configure a maintainer-clean tree and then
> go and build in any random subdirectory without taking care of the
> generated headers.  In principle, we could do something like the hack
> Peter did with temp-install, where it's basically forced to be a
> prerequisite of "make check" in EVERY subdirectory and then we buy back
> some of the inefficiency by making it a no-op in child make runs.  Not
> sure that's a good thing though.

After further contemplation I decided that that was, in fact, the only
reasonable way to improve matters.  If we have multiple subdirectories
independently firing the "make generated-headers" action, then we have
parallel make hazards of just the same sort I was trying to prevent.
So it's really an all-or-nothing proposition.  The MAKELEVEL hack
plus wiring the prerequisite into the recursion rules is the best way
to make that happen.

Hence, done that way.

			regards, tom lane