This is an automated email from the ASF dual-hosted git repository.

alexey pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git


The following commit(s) were added to refs/heads/master by this push:
     new ff69c2e31 [cmake] work around of Gradle-related issues (take 2)
ff69c2e31 is described below

commit ff69c2e312e5385037db214f50605979fd26a9f5
Author: Alexey Serbin <ale...@apache.org>
AuthorDate: Tue Aug 13 20:26:50 2024 -0700

    [cmake] work around of Gradle-related issues (take 2)
    
    This is a follow-up to a1cc227df5d5dc7586d3971135643320682b2709.
    
    Change-Id: I5875d7fff1304be1da93c9f4f9b6fb28bda3bdbb
    Reviewed-on: http://gerrit.cloudera.org:8080/21669
    Tested-by: Kudu Jenkins
    Reviewed-by: Zoltan Chovan <zcho...@cloudera.com>
    Reviewed-by: Abhishek Chennaka <achenn...@cloudera.com>
---
 CMakeLists.txt              | 36 +++++++++++++++++++++---------------
 src/kudu/hms/CMakeLists.txt |  4 +++-
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3ebdd1b1a..4f0471264 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -112,21 +112,7 @@ separate_arguments(GRADLE_FLAGS)
 # When invoking Gradle:
 #   * Log errors only, reducing the verbosity of the Gradle's output
 #   * Make the output better fit for plain consoles, avoiding garbled logs
-#   * Avoid building projects in parallel: when the kudu-subprocess.jar and
-#     the hms-plugin.jar targets are built in parallel, it often ends up with
-#     java.lang.ArrayIndexOutOfBoundsException while building shadowJar
-#     for corresponding Java dependencies, and while it's not yet clear whether
-#     the issue is in shadowJar implementation or elsewhere, it's quite simple
-#     to address the issue by not building multiple Gradle targets concurrently
-#   * Disable the build cache: sometimes, once a build process is interrupted,
-#     follow-up Gradle invocations end up with an error like below, and while
-#     it's not yet clear whether the issue is in not properly invoking Gradle
-#     or it's a bug in signal handling elsewhere, it's quite simple to address
-#     the issue by not using the Gradle's build cache
-#
-#       Cannot lock Java compile cache (...) as it has already been locked by 
this process.
-#
-list(APPEND GRADLE_FLAGS --quiet --console=plain --no-parallel 
--no-build-cache)
+list(APPEND GRADLE_FLAGS --quiet --console=plain)
 list(REMOVE_DUPLICATES GRADLE_FLAGS)
 
 # Initialize Gradle to ensure the wrapper is downloaded.
@@ -150,6 +136,26 @@ add_custom_command(OUTPUT ${PROTO_JAR}
         DEPENDS init_gradle)
 add_custom_target(proto_jar DEPENDS ${PROTO_JAR})
 
+# An artificial target for sequencing of building the subprocess_jar and the
+# hms_plugin_jar targets. The sequencing is to work around the following issues
+# when running multiple gradle instances in parallel, concurrently building
+# the targets:
+#
+#   * Sometimes it ends up with java.lang.ArrayIndexOutOfBoundsException
+#     while building shadowJar for corresponding Java dependencies,
+#     and while it's not yet clear whether the issue is in shadowJar
+#     implementation or elsewhere, it's quite simple to address the issue
+#     by not running multiple Gradle instances concurrently
+#
+#   * Sometimes the following error is reported, as seen elsewhere [1][2]:
+#
+#       Timeout waiting to lock Java compile cache (...). It is currently in 
use by another Gradle instance.
+#
+# [1] https://github.com/gradle/gradle/issues/8375
+# [2] https://github.com/gradle/gradle/issues/11861
+#
+add_custom_target(subprocess_jar_seq DEPENDS subprocess_jar)
+
 # Allow "make install" to not depend on all targets.
 #
 # Must be declared in the top-level CMakeLists.txt.
diff --git a/src/kudu/hms/CMakeLists.txt b/src/kudu/hms/CMakeLists.txt
index cf84f7ca2..eb76c6849 100644
--- a/src/kudu/hms/CMakeLists.txt
+++ b/src/kudu/hms/CMakeLists.txt
@@ -72,7 +72,9 @@ add_custom_command(OUTPUT ${HMS_PLUGIN_JAR}
     "${HMS_PLUGIN_JAR}"
   WORKING_DIRECTORY "${JAVA_DIR}"
   DEPENDS proto_jar)
-add_custom_target(hms_plugin_jar DEPENDS ${HMS_PLUGIN_JAR})
+# NOTE: 'subprocess_jar_seq' is an artificial dependency for 'hms_plugin_jar';
+# see the comment in the project's top-level CMakeLists.txt.
+add_custom_target(hms_plugin_jar DEPENDS ${HMS_PLUGIN_JAR} subprocess_jar_seq)
 
 # The mini_hms is used only for tests.
 if (KUDU_CLI_TEST_TOOL_ENABLED)

Reply via email to