From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers. |
Date: | 2018-04-09 20:46:34 |
Message-ID: | 17755.1523306794@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
I wrote:
> Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-09 20:55:21 | Re: pgsql: Support partition pruning at execution time |
Previous Message | Tom Lane | 2018-04-09 20:42:38 | pgsql: Fix partial-build problems introduced by having more generated h |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-09 20:55:21 | Re: pgsql: Support partition pruning at execution time |
Previous Message | Tomas Vondra | 2018-04-09 20:43:03 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |