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
- fix_pgxs.diff (text/x-patch) patch
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
-
Fix pgxs.mk to not try to build generated headers in external builds.
- 1a40485af6e4 11.0 landed
-
Fix partial-build problems introduced by having more generated headers.
- 3b8f6e75f3c8 11.0 landed
-
Further cleanup of client dependencies on src/include/catalog headers.
- af1a949109d8 11.0 landed
-
Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.
- cefa3871534d 11.0 cited
-
Switch client-side code to include catalog/pg_foo_d.h not pg_foo.h.
- 9c0a0de4c91b 11.0 cited