A brief survey of build tools, focused on D
neia at ikeran.org
Tue Dec 11 04:52:12 UTC 2018
On Mon, 10 Dec 2018 13:01:08 -0800, H. S. Teoh wrote:
> It also requires network access. On *every* invocation, unless
> explicitly turned off. And even then, it performs time-consuming
> dependency resolutions on every invocation, which doubles or triples
> incremental build times. Again, unacceptable.
I feel like those should be configuration options at the very worst. And
dub probably shouldn't even bother verifying your dependencies if you
haven't changed dub.json.
> Then it requires a specific source layout, with incomplete /
> non-existent configuration options for alternatives. Which makes it
> unusable for existing code bases. Unacceptable.
A lot of people do find it acceptable to have a build tool that makes
assumptions about your source code layout, but that's certainly not always
possible or desirable.
> Worst of all, it does not support custom build actions, which is a
> requirement for many of my projects.
Yeah, there's a lot of neat metaprogramming stuff in D (like pegged) where
it's awesome with small projects that it's part of compilation, but when
I'm dealing with a nontrivial instance of it, I want to split it into a
separate build step. Dub doesn't help me accomplish that.
> After so many decades of "advancement", we're still stuck in the
> gratuitously incompatible walled gardens, like the gratuitous browser
> incompatibilities of the pre-W3C days of the Web. And on modern CPUs
> with GHz clock speeds, RAM measured in GBs, and gigabit download speeds,
> building Hello World with a system like dub (or Gradle, for that matter)
> is still just as slow (if not slower!) as running make back in the 90's
> on a 4 *kHz* processor. It's ridiculous.
Solving an NP-complete problem every time you build is not a great start.
> Why can't modern source code come equipped with dependency information
> in a *standard format* that can be understood by *any* build system?
Kythe is an attempt to make the relevant information available in a
language-agnostic way. Might be a reasonable basis for a standardized
build system. No clue how well it works or what it actually supports.
> Build systems shouldn't need to reinvent their own gratuitously
> incompatible DSL just to express what's fundamentally the same old
> decades-worn directed graph. And programmers shouldn't need to repeat
> themselves by manually enumerating individual graph edges (like Meson
> apparently does).
Meson doesn't have you enumerate individual graph edges at that level. It
just doesn't build your project correctly. Change a struct size in one
file, and you get a host of weird errors when another file uses it.
Maven and Gradle also don't really have a DAG like that. If any file
changed, your whole project needs to be rebuilt, and all your dependencies
are immutable. Bazel has a DAG across build rules, not across individual
> - Efficient: the amount of work done by the build should be proportional
> to the size of changes made to the source code since the last build,
> NOT proportional to the size of the entire source tree (SCons fails in
> this regard).
Would be great if the tool could pay attention to whether incremental
builds saved time on average and just do a full build if it's better.
> - Language-agnostic: the build system should be essentially a dependency
> graph resolver. It should be able to compile (possibly via plugins)
> source code of any language using any given compiler, provided such a
> combination is at all possible. In fact, at its core, it shouldn't
> even have the concept of "compilation" at all; it should be able to
> generate, e.g., .png files from POVRay scene description files, run
> image post-processing tools on them, then package them into a tarball
> and upload it to a remote webserver -- all driven by the same
> underlying DAG.
You could support rsync just fine, but if it's just an HTTP upload,
there's no standard way to tell if the server's got the file already.
More information about the Digitalmars-d-announce