On Wed, 2018-02-21 at 12:05 -0700, David Gileadi via Digitalmars-d wrote: > […] > > 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.
It is worth pointing out that traditionally Gradle scripts have been Groovy scripts using the ever evolving and improving Gradle DSL, but that there is now the possibility of using the Kotlin Gradle DSL. Still a programming language with a internal DSL, but using a static compiled language with full type checking and IDE support. Groovy is a dynamic language and so IDE support is not as complete. > 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' > } For truly reproducible builds exact version numbers are good, but as with Dub, etc. Gradle has a notation for allowing less exact version specification. Exact version numbers require just one access to JCenter (as here, but also Maven Central, or any other properly structured repository) to cache the artefact. Using the variability will cause a version check to be made at each build. There is though a Gradle offline mode to avoid this if need be. > 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. Indeed. The Gant and GPars builds need a serious rewrite to get rid of a whole raft of crud. This is the danger of a flexible and open build specification that does not happen with systems that use a purely declarative project specification, e.g. Dub and Cargo. But the openness and flexibility allows for a wider range of possibilities. I shall stick my neck out and say that the current Cargo way of working is going to prove inadequate and extensions, or even a replacement, will happen. The Make → Ant → Maven → Gradle path provides a lot of support for this view regarding Cargo, and I believe Dub. > 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. Me too, which is why I still have a fondness for SCons. Meson has taken the "fixed DSL" road, so not a declarative project statement, but not a full programming language. Fortunately you can still escape to do a bit of Python so not all is lost. > > [1]: https://gradle.org/guides/#getting-started -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part