Practical parallelization of D compilation

[Guillaume Lathoud]

On Wednesday, 8 January 2020 at 19:31:13 UTC, H. S. Teoh wrote:
> Personally I prefer using SCons (https://scons.org/), but there 
> are plenty of similar build systems out there, like tup, Meson, 
> CMake, etc..  There are also fancier offerings that double as 
> package managers like Gradle, but from the sounds of it you're 
> not interested to do that just yet.

Thanks, I'll look at SCons.

> As for using packages or not: I do have some projects where I 
> compile different subsets of .d files separately, for various 
> reasons. Sometimes, it's because I'm producing multiple 
> executables that share a subset of source files. Other times 
> it's for performance reasons, or more specifically, the fact 
> that Vibe.d Diet templates are an absolute *bear* to compile, 
> so I write my SCons rules such that they are compiled 
> separately, and everything else is compiled apart from them, so 
> if no Diet templates change, I can cut quite a lot off my 
> compile times.
>
> So it *is* certainly possible; you just have to be comfortable 
> with getting your hands dirty and writing a few build scripts 
> every now and then. IMO, the time investment is more than worth 
> the reduction in compilation waiting times.

Yes, I can well see the usefulness of package compilation in the 
multiple executables case - I'll keep that idea in mind.

In my case however, there is only one executable at the moment. 
The final linking step does not seem to take too much time.

> [...] And to be frank, a 200+ file project is *far* larger than 
> any of mine, and surely worth the comparatively small effort of 
> spending a couple of hours to write a build script (makefile, 
> SConscript, what-have-you) for?

Maybe, but as mentioned, if the need for a build configuration is 
eliminated in the first place, *and* I get to wait only a few 
seconds to test an idea, I'd rather stick to the current solution 
for now. No maintenance...