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
