Browse Source

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.
master
Ben Liblit 4 years ago
parent
commit
bd42510c6b
  1. 24
      README-Gradle.md
  2. 2
      gradle.properties
  3. 2
      travis/install-gradle
  4. 2
      travis/script-gradle

24
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:
- <a
id="parallel"/>[`--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

2
gradle.properties

@ -0,0 +1,2 @@
org.gradle.caching=true
org.gradle.parallel=true

2
travis/install-gradle

@ -1,3 +1,3 @@
# -*- mode: sh; sh-shell: sh -*-
./gradlew --continue --parallel assemble
./gradlew --continue assemble

2
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

Loading…
Cancel
Save