From bd42510c6beef772fc7896844484ca730de3f39c Mon Sep 17 00:00:00 2001 From: Ben Liblit Date: Sat, 31 Mar 2018 18:21:50 -0500 Subject: [PATCH] Enable both parallel builds and build output caching by default This should give us a nice build-performance boost, both locally and in Travis CI. I've used parallel builds routinely for months now, and they're working fine. Build output caching is newer, but it also seems to be working well and saves us tremendous time on downloads. --- README-Gradle.md | 24 +++++++++++------------- gradle.properties | 2 ++ travis/install-gradle | 2 +- travis/script-gradle | 2 +- 4 files changed, 15 insertions(+), 15 deletions(-) create mode 100644 gradle.properties diff --git a/README-Gradle.md b/README-Gradle.md index 335739c81..8bc742e3d 100644 --- a/README-Gradle.md +++ b/README-Gradle.md @@ -9,7 +9,11 @@ tutorial. - [more comprehensive management of external dependencies](#comprehensive-external-dependencies) -- [`--parallel` for faster builds](#parallel) +- faster builds using [parallel task + execution](https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:parallel_execution) + and [user-scoped + caching](https://docs.gradle.org/current/userguide/build_cache.html) + (both enabled by default) - [trustworthy dependencies for incremental builds](#trustworthy-dependencies-for-incremental-builds) - [composite builds](#composite-builds) for easier integration of WALA @@ -42,13 +46,12 @@ need to avoid this switch. Gradle downloads many packages and supporting Java libraries as needed. Your first Gradle build may take a long time. On a fast workstation with a University-grade network and no local caches, my -initial run of `./gradlew --parallel assemble processTestResources` -took five minutes. On a decent laptop with residential DSL and no -local caches, the same initial build took twenty minutes. -Fortunately, user- and project-level Gradle caches will make -incremental rebuilds much faster. Rerunning `./gradlew --parallel -assemble processTestResources` with a warm cache in an already-built -tree takes under three seconds. +initial run of `./gradlew assemble processTestResources` took five +minutes. On a decent laptop with residential DSL and no local caches, +the same initial build took twenty minutes. Fortunately, user- and +project-level Gradle caches will make incremental rebuilds much +faster. Rerunning `./gradlew assemble processTestResources` with a +warm cache in an already-built tree takes under three seconds. Maven is the same, really. You may already have most of what Maven needs downloaded and cached locally, but your first Maven WALA build @@ -194,11 +197,6 @@ as `procTeRes` or even `pTR`. Among Gradle’s command-line flags, I have found the following particularly useful: -- [`--parallel`](https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:parallel_execution): - use multiple CPUs to build multiple independent sub-targets - simultaneously. There’s rarely any good reason *not* to use this. - - [`--continue`](https://docs.gradle.org/current/userguide/command_line_interface.html#sec:continue_build_on_failure): keep building non-dependent sub-tasks even after an initial failure. Especially useful in conjunction with the `build` or `test` tasks to diff --git a/gradle.properties b/gradle.properties new file mode 100644 index 000000000..aec0a559b --- /dev/null +++ b/gradle.properties @@ -0,0 +1,2 @@ +org.gradle.caching=true +org.gradle.parallel=true diff --git a/travis/install-gradle b/travis/install-gradle index ac73a808c..163901c61 100644 --- a/travis/install-gradle +++ b/travis/install-gradle @@ -1,3 +1,3 @@ # -*- mode: sh; sh-shell: sh -*- -./gradlew --continue --parallel assemble +./gradlew --continue assemble diff --git a/travis/script-gradle b/travis/script-gradle index a382f2a59..1a74967bc 100644 --- a/travis/script-gradle +++ b/travis/script-gradle @@ -5,4 +5,4 @@ case "$TRAVIS_OS_NAME" in (osx) headless='' ;; esac -$headless ./gradlew --continue --parallel build javadoc lintGradle +$headless ./gradlew --continue build javadoc lintGradle