RFR: 8201788: Number of make jobs wrong for bootcycle-images target

Severin Gehwolf sgehwolf at redhat.com
Thu Apr 19 14:46:09 UTC 2018


Hi,

Bug: https://bugs.openjdk.java.net/browse/JDK-8201788

I'd like to get a fix in for an old discussion which already happened a
while ago:
http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html

The issue is that for bootcycle-images target a recursive call to make
is being called with 'JOBS=""' which results in a call to "make -j".
Thus, make is free to use as many jobs as it would like. This may cause
for the occasional build failure. It has for us in the past.

In this old thread above a patch like this was discouraged, unless I
misunderstood something.

diff --git a/make/Main.gmk b/make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -321,7 +321,7 @@
         ifneq ($(COMPILE_TYPE), cross)
          $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
          +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
-             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
+             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
         else
          $(call LogWarn, Boot cycle build disabled when cross compiling)
         endif

It's my understanding that such a fix would pass down the relevant JOBS
setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
call? What am I missing? If somebody wants to shoot themselves in the
foot by doing:

configure ...
make JOBS=

That should be fine as it would just result in "make -j" calls without
arguments. The common case where the JOBS setting comes from configure
would be fixed, though. bootcycle-images target would result in "make
-j <num-cores>".

Thoughts? Suggestions?

Thanks,
Severin


More information about the build-dev mailing list