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