A brief survey of build tools, focused on D

[Neia Neutuladh]

On Sun, 16 Dec 2018 00:17:55 +0000, Paul Backus wrote:
> On Wednesday, 12 December 2018 at 22:41:50 UTC, H. S. Teoh wrote:
>> It's time we came back to the essentials.  Current monolithic build
>> systems ought to be split into two parts: [...]
> You're missing (0) the package manager, which is probably the biggest
> advantage "monolothic" build tools like dub, cargo, and npm have
> compared to language-agnostic ones like make.

If I were to make a new build tool and wanted package manager integration, 
I'd choose Maven as the backend. This would no doubt be more frustrating 
than just making my own, but there would hopefully be fewer bugs on the 
repository side.

(I might separately make my own Maven-compatible backend.)

> There's something important you're glossing over here, which is that, in
> the general case, there's no single obvious or natural way to compose
> two DAGs together.

You do it like Bazel.

In Bazel, you have a WORKSPACE file at the root of your project. It 
describes, among other things, what dependencies you have. This might, for 
instance, be a git URL and revision. All this does is expose that 
package's build rules to you.

Separately, you have build rules. Each build rule can express a set of 
dependencies on other build rules. There's no difference between depending 
on a rule that your own code defines and depending on one from an external 
dependency.

It might be appropriate to have a hint on DAG nodes saying that this is 
the default thing that you should probably depend on if you're depending 
on the package. A lot of projects only produce one artifact for public 
consumption.