I believe only truly practical approach is to design a D build
tool as a library (and, ideally, make it a Phobos module). But at
the same time it is important to keep it generic and not tied to
D or building application in general.
There are two important bits here (important for me):
1)
It must be designed in terms of "target - script - dependency"
abstractions, similar to make or tup. I will never use anything
that pretends to be a build tool but keeps imagining build
process as "compile and link bunch of files and libraries". Good
litmus test is this makefile target chain we have in one of
projects (very simplified):
bin/app: src/app/main.d protocol.o
# compile app
src/app/main.d: $(D_SOURCES)
protocol.d: protocol.h
# use dstep
protocol.h protocol.c: protocol.proto
# use proto-c, protocol buffer C compiler
Anything that does not allow me to express such dependency chain
in native straightforward manner without resorting to external
scripts is simply not good enough. dub fails this, CMake fails
this.
2)
D is only cross-platfrom scripting language we can rely on. This
is probably biggest problem of make (apart from bunch of legacy
syntax crap) - any real build system needs relatively complicated
build rules for target transformation. However we can reasonably
expect working D compiler from anyone wanting to compile D
project - which is both perfectly cross-platform and does not
request installation of any additional binaries.
