Julien Rouhaud writes:
> On Tue, Apr 10, 2018 at 6:58 PM, Tom Lane wrote:
>> none of the three if-guards in the temp-install rule itself should
>> prevent this, so what is preventing it? I don't see it.
> I just checked, and for the record the second rule (ifneq
> ($(abs_top_builddir),) is actu
On Tue, Apr 10, 2018 at 6:58 PM, Tom Lane wrote:
>
> Well, the question that's bothering me is how come "make check" in
> an external build doesn't try to execute the temp-install rule before
> printing that error message. Experimentation shows that it doesn't,
> but it sure looks to me like it s
Julien Rouhaud writes:
> On Tue, Apr 10, 2018 at 3:46 PM, Tom Lane wrote:
>> Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
>> makefile. I don't know whether "make check" could be useful in a PGXS
>> build, but certainly that recipe for making a temp install isn't gon
On Tue, Apr 10, 2018 at 3:46 PM, Tom Lane wrote:
>
> Julien Rouhaud writes:
>> I think the best fix if to define NO_GENERATED_HEADERS in pgxs.mk,
>> patch attached.
>
> Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
> makefile. I don't know whether "make check" could
Julien Rouhaud writes:
> Compilation of external extensions using PGXS appears to be broken
> since this commit:
Ouch, sorry.
> I think the best fix if to define NO_GENERATED_HEADERS in pgxs.mk,
> patch attached.
Hm. I wonder if we don't also want NO_TEMP_INSTALL, like the doc/src/sgml
makefil
On Tue, Apr 10, 2018 at 10:08:16AM +0200, Julien Rouhaud wrote:
> 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/pgbu
Hi,
On Mon, Apr 9, 2018 at 10:46 PM, Tom Lane 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 o
On Mon, Apr 09, 2018 at 04:46:34PM -0400, Tom Lane 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 hazard
I wrote:
> Michael Paquier 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 n
Michael Paquier 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
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 seems like a bit of a brute-force solution, thou
Michael Paquier writes:
> On Sun, Apr 08, 2018 at 06:35:39PM +, Tom Lane wrote:
>> Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.
> This patch or one of its relatives has visibly broken parallel builds
> for me. "make -j 4 install" directly called after a configure complains:
On Sun, Apr 08, 2018 at 06:35:39PM +, Tom Lane wrote:
> Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.
>
> Traditionally, include/catalog/pg_foo.h contains extern declarations
> for functions in backend/catalog/pg_foo.c, in addition to its function
> as the authoritative definit
13 matches
Mail list logo