Git, the D package manager

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Fri Feb 6 03:37:08 PST 2015


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.


More information about the Digitalmars-d mailing list