A brief survey of build tools, focused on D

[H. S. Teoh]

On Tue, Dec 11, 2018 at 09:54:06AM +0000, Atila Neves via Digitalmars-d-announce wrote:
[...]
> No reggae? https://github.com/atilaneves/reggae/

I recently finally sat down and took a look at Button, posted here a few
years ago.  It looked pretty good.  One of these days I really need to
sit down and take a good look at reggae.


> dub is simple and has dependency management, and that's about it.
> Speed?  It's as slow as molasses and hits the network every time
> unless explicitly told not to. Never mind if there's already a
> dub.selections.json file and all of the dependencies are fetched
> (which it could check but doesn't).

According to Sönke's post elsewhere in this thread, these performance
issues have been addressed in the latest version.  I haven't tried it
out to verify that yet, though.


> Trying to do anything non-trivial in dub is a exercise in frustration.
> The problem is that it's the de facto D package manager, so as soon as
> you have dependencies you need dub whether you want to or not.

After fighting with dub for 2 days (or was it a week? it certainly felt
longer :-P) in my vibe.d project, I ended up just creating an empty
dummy project in a subdirectory that declares a dependency on vibe.d,
and run dub separately to fetch and build vibe.d, then I ignore the rest
of the dummy project and go back to the real project root and have SCons
build the real executable for me.  So far, that has worked reasonably
well, besides the occasional annoyance of having to re-run dub to update
to the latest vibe.d packages.


> dub works great if you're writing an executable with some dependencies
> and hardly any other needs. After that...

Yeah.  Being unable to handle generated source files is a showstopper
for many of my projects.  As Neia said, while D has some very nice
compile-time codegen features, sometimes you really just need to write
an external utility that generates source code.

For example, one of my current projects involves parsing GLSL source
files and generating D wrapper code as syntactic sugar for calls to
glUniform* and glAttrib* (so that I can just say `myshader.color =
Vector(1, 2, 3);` instead of manually calling glUniform* with fiddly,
error-prone byte offsets.  While in theory I could use string imports
and CTFE to do this, it's far less hairy to do this as an external step.

Most build systems with automatic dependency extraction would fail when
given this sort of setup, because they generally depend on scanning
directory contents, but in this case the file may not have been
generated yet (it would not be generated until the D code of the tool
that generates it is first compiled, then run). So the dependency would
be missed, resulting either in intermittent build failure or failure to
recompile dependents when the generated code changes.  It's not so
simple to just do codegen as a special preprocessing step -- such tasks
need to be treated as 1st class dependency tasks and handled natively as
part of DAG resolution, not as something tacked on as an afterthought.


T

-- 
Music critic: "That's an imitation fugue!"