Dub, Cargo, Go, Gradle, Maven

David Gileadi gileadisNOSPM at gmail.com
Wed Feb 21 19:05:17 UTC 2018


On 2/21/18 10:30 AM, H. S. Teoh wrote:
> I think the ideal situation straddles the divide between declarative
> build specs and a full-fledged general programming language.  You don't
> want it to get too general, lest you end up with the build equivalent of
> spaghetti code where the build script becomes unreadable and
> unmaintainable.  OTOH a purely declarative approach is limited by how
> well the DSL is designed.  An insufficiently-expressive declarative
> language leads to much frustration when you find yourself unable to
> express something that you need to do with your build.

Working in the Java world, I was extremely happy when I discovered 
Gradle. It looks declarative thanks to the Groovy language, but you can 
easily mix 'n' match more imperative code inline.

For a taste of Gradle, here's a Java-centric build file from their 
getting-started guides [1]:

```
apply plugin: 'java'
apply plugin: 'application'

repositories {
     jcenter()
}

dependencies {
     compile 'com.google.guava:guava:21.0'
     testCompile 'junit:junit:4.12'
}

mainClassName = 'App'
```

And here's a C++ one:

```
apply plugin: 'cpp'

model {
     components {
         main(NativeExecutableSpec)
     }
}
```

Of course in the real world build files get bigger and more complex, but 
to me they tend to remain very readable.

Comparing Java's Maven and Gradle (and in the JS world, Grunt and Gulp) 
have given me a strong preference for code-based build scripts, as long 
as they remain readable.

[1]: https://gradle.org/guides/#getting-started


More information about the Digitalmars-d mailing list