A brief survey of build tools, focused on D

[Olivier FAURE]

On Sunday, 16 December 2018 at 00:17:55 UTC, Paul Backus wrote:
> 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.
>
> For example: suppose project A's DAG has two "output" vertices 
> (i.e., they have no outgoing edges), one corresponding to a 
> "debug" build and one corresponding to a "release" build. Now 
> suppose project B would like to depend on project A. For this 
> to happen, our hypothetical DAG import function needs to add 
> one or more edges that connect A's DAG to B's DAG. The question 
> is, how many edges, and which vertices should these edges 
> connect?

That doesn't seem right.

Surely you could write

     externalDependencies = [ someSubmodule.release ]

in your language-specific build tool, and have it convert to an 
equivalent import edge targeting the correct vertice in the 
standardized dependency graph?

It might be inconvenient in some cases (eg you have to manually 
tell your tool to import someSubmodule.release in release mode 
and someSubmodule.debug in debug mode), but it would still be 
infinitely more convenient and elegant than the current "multiple 
incompatible build tools per language, and shell/make scripts to 
link them together" paradigm.

Especially with the increasing usability of WebAsm, it would be 
nice to have a standard build model to link multiple modules in 
different languages together into a single wasm binary.

A standardized DAG model would also help making a project-wide 
equivalent to the Language Server Protocol. (I'm not convinced by 
BSP)