D compilation is too slow and I am forking the compiler

[Vladimir Panteleev]

On Wednesday, 21 November 2018 at 11:35:02 UTC, Atila Neves wrote:
> I'm also currently working on a project to save my bloodstream 
> from the cortisol drip that happens when anything a computer 
> does takes over a second, which these days means waiting for 
> dmd to compile my code so I can see the result of the tests. 
> I'll share more details when I have time.

Looking forward to it!

> But: one of the things I want to do is a version of this / 
> precompiled headers. I've complained before that compiling 
> std.path with -unittest takes forever (0.5s or so, and most of 
> it due to std.uni). That's a price I pay every time I make a 
> one line change to any file, and the linker hasn't even been 
> invoked yet. Here's the thing: Phobos only changes from one 
> release to the next. Why am I waiting to recompile a read-only 
> file that won't change unless I update the compiler, over and 
> over again?

That particular problem is in large part due to that the 
-unittest switch is not namespaced. I ran into the same issue 
with -allinst - with std.path, it breaks only if -unittest is 
also specified. I don't want to compile std.path unit tests, just 
my own!

Have we tried disabling -unittest for modules that aren't on the 
compiler's command line yet (or, in case of -i, not excluded)?

> I'd love it if I could precompile Phobos and just use the 
> digested information every time I'm iterating.

I agree, it would be nice if we could ship some "precompiled 
module" files along with Phobos .lib / .so files, but it looks 
like implementing this feature correctly might be non-trivial.

Maybe this hack could be developed further into a more generic 
"compiler server" idea.