Dub, Cargo, Go, Gradle, Maven

[H. S. Teoh]

On Fri, Feb 16, 2018 at 07:31:37PM +0000, Dmitry Olshansky via Digitalmars-d wrote:
> On Friday, 16 February 2018 at 18:16:12 UTC, H. S. Teoh wrote:
[...]
> > 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.

This assumes that the upstream server (1) consistently serves the same
data for the same version -- which in principle will be the case, but
unforeseen problems could break this assumption; (2) stores all versions
forever, which is unlikely to be always true.

In any case, dependence on network access for every invocation of a
build is unacceptable to me.


[...]
> 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.

Personally, I find that the most useful build systems are those that
make no assumptions about how your products are built.  SCons is a good
example of this: for example, currently I have a website completely
built from ground-up by SCons, which includes tasks like generating
datasets, 3D models, using a PHP filter to generate HTML, running a
raytracer to generate images, post-processing generated images, creating
a dataset from revision history and rendering graphs, running LaTeX to
generate PDF documentation, etc., and installing the products of all of
the foregoing into a staging directory that then gets rsync'd to the
remote webserver.  Basically none of these steps involve the traditional
invocation of a compiler or built-in source code dependency resolution.
SCons has a very nice API for defining my own dependency resolver for
custom data formats that can leverage all of the built-in scanning /
depending resolving algorithms that come with SCons.

I would not even consider any build system incapable of this level of
customization.


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan