From make: Special Targets:

.NOTPARALLEL

If .NOTPARALLEL is mentioned as a target, then this invocation of make will be run serially, even if the ‘-j’ option is given. Any recursively invoked make command will still run recipes in parallel (unless its makefile also contains this target). Any prerequisites on this target are ignored.

Will this make the entire build non-parallel? If so, that would be bad.

Will this make the entire build non-parallel? If so, that would be bad.

As @fanquake posted

Any recursively invoked make command will still run recipes in parallel

The code building targets are still can run in parallel because they are in src/Makefile, this change only affect the target in the top Makefile.

ok utACK from me in that case

If there's a race condition, something's broken. We should clarify the dependencies rather than serializing. Any idea where things break down?

Agree with @theuni, looks like this avoids a problem instead of fixing it.

I think that this should be enough to fix it. Untested:

diff --git a/Makefile.am b/Makefile.am
index 8a8debb..3a725d3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,7 +95,7 @@ $(OSX_APP)/Contents/Resources/bitcoin.icns: $(OSX_INSTALLER_ICONS)
        $(MKDIR_P) $(@D)
        $(INSTALL_DATA) $< $@

-$(OSX_APP)/Contents/MacOS/Bitcoin-Qt: $(BITCOIN_QT_BIN)
+$(OSX_APP)/Contents/MacOS/Bitcoin-Qt: all-recursive
        $(MKDIR_P) $(@D)
        STRIPPROG="$(STRIP)" $(INSTALL_STRIP_PROGRAM)  $< $@

I believe the issue is that the top-level calls a sub-make for all, as well as for src/qt/bitcoin-qt, and those end up racing. Solve that by having deploy depend on the sub-make already being complete, which also matches the way the Windows dependencies are handled.

As a side-effect, this makes make deploy do what you wanted it to do in the beginning :)

@theuni Fixed

utACK cf01fd6, makes sense!

@ken2812221 Thanks!

Tested locally. I can easily reproduce the racy build failure in master, and this appears to fix it.