A brief survey of build tools, focused on D

[H. S. Teoh]

On Tue, Dec 11, 2018 at 09:58:39AM +0000, Atila Neves via Digitalmars-d-announce wrote:
> On Monday, 10 December 2018 at 22:18:28 UTC, Neia Neutuladh wrote:
[...]
> In typical D code, it's usually faster to compile per package than
> either all-at-once or per module. Which is why it's the default in
> reggae.

Yeah, for projects past a certain size, compiling per package makes the
most sense.


[...]
> > From discussions on IRC about reducing compile times, though, using
> > Phobos is a good way to get slow compilation, and I use Phobos. That
> > alone means incremental builds are likely to go long.
> 
> Yes. Especially with -unittest.

We've talked about this before.  Jonathan Marler actually ran a test and
discovered that it wasn't something *directly* to do with unittests; the
performance hit was coming from some unexpected interactions with the
way the compiler instantiates templates when -unittest is enabled.  I
don't remember what the conclusion was, though.

Either way, the unittest problem needs to be addressed.  I've been
running into problems with compiling my code with -unittest, because it
causes ALL unittests of ALL packages to be compiled, including Phobos
and external libraries.  It's making it very hard to manage exactly what
is unittested -- I want to unittest my *own* code, not any 3rd party
libraries or Phobos, but right now, there's no way to control that.

Recently I ran into a roadblock with -unittest: I have a project with
rather extensive unittests, but it assumes certain things about the
current working directory and the current environment (because those
unittests are run from a special unittest driver). I have that project
as a git submodule in a different project for experimental purposes, but
now I can't compile with -unittest because the former project's
unittests will fail, not being run in the expected environment. :-(

There needs to be a more fine-grained way of controlling which unittests
get compiled.  Generally, I don't see why I should care about unittests
for external dependencies (including Phobos) when what I really want is
to test the *current* project's code.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL