Actually, dmd is so fast I never bother with these "build" utilities. I
just send it all the files and have it rebuild everytime, deleting all
the o files afterward.
This is very fast, even for larger projects. It appears (to me) the
static cost of calling dmd is much greater than the dynamic cost of
compiling a file. These toolkits always compile a, then b, then c,
which takes like 2.5 times as long as compiling a, b, and c at once.
That said, if dmd were made to link into other programs, these toolkits
could hook into it, and have the fixed cost only once (theoretically) -
but still dynamically decide which files to compile. This seems ideal.
-[Unknown]
davidl wrote:
1. compiler know in what situation a file need to be recompiled
Consider the file given the same header file, then the obj file of this
will be required for linking, all other files import this file shouldn't
require any recompilation in this case. If a file's header file changes,
thus the interface changes, all files import this file should be
recompiled.
Compiler can emit building command like rebuild does.
I would enjoy:
dmd -buildingcommand abc.d > responsefile
dmd @responsefile
I think we need to eliminate useless recompilation as much as we should
with consideration of the growing d project size.
2. maintaining the build without compiler support costs
