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