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
signature.asc
Description: This is a digitally signed message part
