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