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