Dub, Cargo, Go, Gradle, Maven

[Russel Winder]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20180222/7cb53191/attachment-0001.sig>