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.
Date: Mon, 09 Apr 2018 13:21:49 -0400
Message-ID: <6629.1523294509@sss.pgh.pa.us> (raw)
In-Reply-To: <20180409061354.GD1740@paquier.xyz>
References: <E1f5FAB-0006LU-MB@gemulon.postgresql.org>
<20180409010031.GA11599@paquier.xyz>
<16609.1523243109@sss.pgh.pa.us>
<20180409061354.GD1740@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Apr 08, 2018 at 11:05:09PM -0400, Tom Lane wrote:
>> Hm. I'd tested "make -j all", but not going directly to "install".
>> Does it help if you add
>> $(SUBDIRS:%=install-%-recurse): | submake-generated-headers
>> to src/Makefile?
> 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.
Independently of that, though, I noticed that part of the issue in your
"make install" example is that relpath.c, along with some other frontend
code, includes catalog/catalog.h which includes pg_class.h (and thereby
now pg_class_d.h). Since src/common/Makefile thinks the only generated
header it needs to worry about is errcodes.h, building src/common first
now falls over. But allowing frontend code to include catalog.h is
pretty insane: that pulls in relcache.h as well, and surely we don't
want to tie our hands to the point that relcache.h has to be frontend
clean.
What we need to do is take OIDCHARS and TABLESPACE_VERSION_DIRECTORY
out of catalog.h and put them in some more frontend-friendly header.
My first thought was pg_tablespace_d.h, but my second one is relpath.h.
Comments?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, 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>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox