Re: build farm machine using <make -j 8> mixed results

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I have just repeated this on an absolutely fresh up to date F17 machine,
> with no symlink stuff in play.

> Steps to recreate:

> CC="ccache gcc" ../postgres/configure --enable-depend --enable-debug
> --enable-cassert --with-perl --with-python --with-tcl --with-libxml
> --with-libxslt -with-openssl --with-gssapi --with-pam --with-ldap
> make -j 4

Huh ... that recipe works (er, fails) for me too, at least some of the
time. I wonder what exactly is the key difference between the working
and failing cases?

Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.NOTPARALLEL in ecpg/Makefile, because there are several reasons not
to run its sub-makes in parallel:

* preproc/Makefile casually does this:

../ecpglib/typename.o: ../ecpglib/typename.c
$(MAKE) -C $(dir $@) $(notdir $@)

which is very likely to screw up any make proceeding in parallel in
ecpglib.

* compatlib and ecpglib will equally casually invoke "make all" in
other subdirectories; ditto.

And that's not even counting the bison-output problem you were seeing.
I'm not entirely sure what's causing that, but I'm suspicious that the
ultimate cause is the extra rules for the "all...recurse" targets in
ecpg/Makefile, which look like they could result in additional instances
of multiple make processes running in the same subdirectory.

After adding the .NOTPARALLEL marker, I don't see these failures
anymore.

regards, tom lane