Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-10T08:08:16Z
Lists: pgsql-hackers

Attachments

Hi,

On Mon, Apr 9, 2018 at 10:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Compilation of external extensions using PGXS appears to be broken
since this commit:

make[1]: *** /tmp/pgbuild/lib/postgresql/pgxs/src/makefiles/../../src/backend:
No such file or directory.  Stop.
make: *** [/tmp/pgbuild/lib/postgresql/pgxs/src/makefiles/../../src/Makefile.global:370:
submake-generated-headers] Error 2


I think the best fix if to define NO_GENERATED_HEADERS in pgxs.mk,
patch attached.

Commits

  1. Fix pgxs.mk to not try to build generated headers in external builds.

  2. Fix partial-build problems introduced by having more generated headers.

  3. Further cleanup of client dependencies on src/include/catalog headers.

  4. Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.

  5. Switch client-side code to include catalog/pg_foo_d.h not pg_foo.h.