A brief survey of build tools, focused on D

Sönke Ludwig sludwig+d at outerproduct.org
Tue Dec 11 10:26:45 UTC 2018

Am 10.12.2018 um 22:01 schrieb H. S. Teoh:
> (...)
> Convenience and simplicity, sure.  But speed? I'm sorry to say, I tried
> dub for 2 days and gave up in frustration because it was making my
> builds *several times longer* than a custom SCons script.  I find that
> completely unacceptable.
> It also requires network access.  On *every* invocation, unless
> explicitly turned off.  And even then, it performs time-consuming
> dependency resolutions on every invocation, which doubles or triples
> incremental build times.  Again, unacceptable.

The upgrade check has been disabled in one of the latest releases, so 
unless the dependencies haven't been resolved before, it will not access 
the network anymore. A notable exception are single-file packages, which 
don't have a dub.selections.json - we should probably do something about 
this, too, at some point.

I've also rewritten the dependency resolution a while ago and it usually 
is not noticeable anymore nowadays.

Then there was an issue where LDC was invoked far too frequently to 
determine whether it outputs COFF files or not, making it look like 
scanning the file system for changes took unacceptably long. This has 
also been fixed.

The main open point right now AFAICS is to make --parallel work with the 
multiple-files-at-once build modes for machines that have enough RAM. 
This is rather simple, but someone has to do it. But apart from that, I 
think that the current state is relatively fine form a performance point 
of view.

> Then it requires a specific source layout, with incomplete /
> non-existent configuration options for alternatives.  Which makes it
> unusable for existing code bases.  Unacceptable.

You can define arbitrary import/source directories and list (or delist) 
source files individually if you want. There are restrictions on the 
naming of the output binary, though, is that what you mean?

> Worst of all, it does not support custom build actions, which is a
> requirement for many of my projects.  It does not support polyglot
> projects. It either does not support explicit control over exact build
> commands, or any such support is so poorly documented it might as well
> not exist.  This is not only unacceptable, it is a show-stopper.

Do you mean modifying the compiler invocations that DUB generates or 
adding custom commands (aka pre/post build/generate commands)?

More information about the Digitalmars-d-announce mailing list