Re: Fixing parallel make of libpq

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> OK, got that. But that doesn't directly answer the question of whether
> it's wrong to use a phony target as an order-only prerequisite of
> another phony target. Grepping around for other possible issues,
> I see that you recently added
>
> update-unicode: | submake-generated-headers submake-libpgport
> $(MAKE) -C src/common/unicode $@
> $(MAKE) -C contrib/unaccent $@
>
> Doesn't that also have parallel-make hazards, if libpq does?

The part of 'update-unicode' that needs the generated headers and
libpgport is src/common/unicode/norm_test, which is depended by on by
the normalization-check target in the same directory. Running 'make -C
src/common/unicode normalization-check' in a freshly-configured tree
does indeed fail, independent of parallelism or the update-unicode
target.

Adding the deps to the norm_test target fixes 'make -C
src/common/unicode normalization-check', but 'make -C src/common/unicode
update-unicode' still fails, because submake-generated-headers only does
its thing in the top-level make invocation, so that needs an explicit
dep as well.

Please find a patch attached. However, I don't think it's fair to block
fixing the actual libpq parallel-make bug that has bitten me several
times on auditing the entire source tree for vaguely related issues that
nobody has complained about yet.

- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen