Dub, Cargo, Go, Gradle, Maven

[Dmitry Olshansky]

On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
> On Mon, Feb 12, 2018 at 10:35:06AM +0000, Russel Winder via 
> Digitalmars-d wrote:
>> In all the discussion of Dub to date, it hasn't been pointed 
>> out that JVM building merged dependency management and build a 
>> long time ago. Historically:
>> 
>>   Make → Ant → Maven → Gradle
>> 
>> and Gradle can handle C++ as well as JVM language builds.
>> 
>> So the integration of package management and build as seen in 
>> Go, Cargo, and Dub is not a group of outliers. Could it be 
>> then that it is the right thing to do. After all package 
>> management is a dependency management activity and build is a 
>> dependency management activity, so why separate them, just 
>> have a single ADG to describe the whole thing.
>
> I have no problem with using a single ADG/DAG to describe the 
> whole thing.  However, a naïve implementation of this raises a 
> few issues:
>
> If a dependent node requires network access, it forces network 
> access every time the DAG is updated.  This is slow, and also 
> unreliable: the shape of the DAG could, in theory, change 
> arbitrarily at any time outside the control of the user.

Oh, come on. Immutable artifacts make this matter trivial - the 
first step is resolution, where you figure out what things you 
already have by looking at metadata only, followed by download 
the world (or part you do not have). Since specific versions 
never change, nothing to worry about. Java folks had this for 
ages with Maven and its ilk.

Some targets like deploy may indeed not have a cheap “check if 
its done” step. They may not realy need one. (though rsync does 
wonders at minimizing the work)

Also most if not all build systems will inevitably integrate all 
of the below in some way:
- compiler (internal as library or external as a build server)
- source code dependency resolution
- package dependency resolution
- package download or build
- execution of arbitrary tasks in form of plugins or external 
tools

Me personally in love with plugins and general purpose language 
available to define tasks. Scala’s SBT may have many faults but 
plugins and extensibility make it awesome.