Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-09T20:46:34Z
Lists: pgsql-hackers
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
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