Avoid concurrency issue when make multiple target #13465

From #13406, changed travis job target for Mac to all deploy, but this could cause a race condition. Simply add .NOTPARALLEL to avoid it. Related jobs: https://travis-ci.org/bitcoin/bitcoin/jobs/391863281 https://travis-ci.org/bitcoin/bitcoin/jobs/391907335 Close #13469

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.