A brief survey of build tools, focused on D
neia at ikeran.org
Sun Dec 16 00:42:52 UTC 2018
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
(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
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
More information about the Digitalmars-d-announce