DUB - call to arms

[Dragos Carp]

On Wednesday, 17 April 2019 at 16:03:24 UTC, H. S. Teoh wrote:
> The idea behind this is that in order to avoid baking in 
> support for a multitude of build systems (make, scons, meson, 
> gradle, whatever) into dub, which will inevitably be 
> unmaintained and out-of-date 'cos is too much work to keep up 
> with everything, we delegate the job to individual packages.  
> There would be one package per external build system, e.g., a 
> 'make' package for make support, an 'scons' package for scons 
> support, and so on.  These packages don't have to do very much, 
> all they need is to (1) define a way of installing said build 
> system, in a way that can be used by dub via a standard 
> interface, and (2) export various command-line templates that 
> dub will use for invoking the build system.
> [...]

Invoking the external tools is probably doable, the problem is 
consuming artifacts generated by these tools. Then there are the 
specialties of each tool: some distinguish between configuration 
(done once for a fresh build) and build, some are very good at 
tracking the dependencies and incremental builds, some rediscover 
the world on each invocation, some support cross-compiling, some 
use command line parameter for customizing the build, other use 
configuration files, some support debug builds, some support 
listing the build targets, some support a server mode, some 
require a server mode, some deprecate features over time, etc., 
etc. Finally, it's a mess.

There is an effort in Scala world to do something in the same 
direction (they have a lot of build systems): 
https://github.com/scalacenter/bsp/blob/master/docs/bsp.md. But 
this effort resumes itself to just IDE integration.

What I'm missing is the tool for building D projects, do you 
suggest that each project should use what it seams fit, or just 
stick with dub?

> It would help if somebody can provide a concrete example of a 
> complex dependency graph that requires anything more than a 
> straightforward topological walk.

I don't know if I understand you right, but probably having some 
generated code, or calling shell scripts with side-effects 
already complicates the problem enough.