On Friday, 16 February 2018 at 22:48:55 UTC, H. S. Teoh wrote:
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;
Trivially enforced on public hubs such maven central.
(2) stores all versions forever, which is unlikely
to be always true.
Is in fact true. After all github stores the whole git repo why
would storing all distinct versions be too much.
In any case, dependence on network access for every invocation
of a build is unacceptable to me.
Well, it is not in the scheme outlined. Only the clean build is.
[...]
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.
No thanks, I’d prefer convention then unique snowflake build
scripts if there us a choice. Sometimes you have to do go beyound
ghe basics but not too often.
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
All of that can be done by any of modern tools with full language
+ DSL at your disposal, eg Gradle or SBT. In a sense SCons is the
same but without resolving packages.
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
