Gradle Schmadel

The new Android IDE is moving to Gradle as it’s build system. I’ve been using and designing build systems for 20+ years.  If you can name a build system I’ve probably used it.  If not, most likely some derivation of it.

Here’s the thing about build systems:

  1. at the end of the day, you’re running command line operations. Compilers, linkers, etc.
  2. all other aspects of the build system must support #1.
  3. if it’s not #1 or #2 it’s either a waste of time or will cause confusion.

There are many things you can do to support how efficiently you can do #1.  For example, you can use ANT to copy files around.  No matter what, you will always come back to : compile -> link -> package -> install.  And those are command line operations.

With that in mind I peek at Gradle.

The First Build Script

Chapter 6 of the Gradle manual has the basic build script.  It’s very telling:


task hello {
    doLast {
        println 'Hello world!'

A few things jump out at me right away:

  1. defining a task means people will be defining task dependencies.  In a build system dependencies exist between files.  Period.  So it’s already clear that Gradle is addressing this by some round-about way.
  2. the notion of doLast tells you build commands are executed in some arbitrary order, but not from top to bottom of the build script.
  3. doLast also means that there are function dependencies. You’ll be building up a mental map of function calls in a build system.
  4. the build script language is seems as lexically complicated as a source code language. There’s not much different between that and the Java Hello World application, for example.
  5. it takes five lines of code to output of “Hello World.”  That’s four lines more than a a UNIX script takes:
echo Hello World!

Will Gradle compensate for these five things in some way?

Time will tell.