Dub, Cargo, Go, Gradle, Maven

[Russel Winder]

On Fri, 2018-02-16 at 14:48 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> 
> 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.

JCenter and Maven Central do indeed serve all versions of all packages
ever stored for all time. It is critical to the JVM-verse that this is
the case.

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

Local caching deals with this.

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

I have been (still am?) a SCons fan but it has some serious problems in
some workflows.

I think all of the things you mention are solved in a system that has a
general purpose programming language to describe the project and the
build. There is clearly a tension between specifying a project in a
purely declarative way (cf. Cargo, Dub, Maven) where all build and
deploy activities are effectively hardwired (though Maven has plugins
to amend things) versus systems that use a programming language. Then
there are two types of the latter: just use a programming language with
a declarative internal DSL, e.g. SCons, Gradle, and those using an
external DSL, e.g. CMake, Meson. I much prefer using a programming
language with internal DSL generally, but then systems like CMake and
Meson get forced on you so you have to begin to like them for certain
situation (*).


(*) Debian has a downer on SCons for building packages for example, and
Meson actually works very well in that context.
  

-- 
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/20180221/9c64f530/attachment-0001.sig>