Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/13 Nick Sabalausky <a at a.a>:
> "Jacob Carlborg" <doob at me.com> wrote in message
> news:ivke5k$2m78$1 at digitalmars.com...
>>
>> First I have to say that I know you are doing this because you want to use
>> D as the language for the build scripts. The reason I did choose Ruby
>> because I think D will be too verbose and when I'm looking at drakefile.d
>> I do think it's too verbose.
>
> Yea, D is likely to be a little more verbose than what could be done in Ruby
> (or Python). Personally, I think that's well worth it, though. I don't know
> how many others would agree or not.
>

Not trying to be argumentative, but what exactly do you see as the
gains in having a D-buildtool built in D (or D-specific build-tool in
any language, for that matter)? Seriously, I'm really asking, since
I'm having a hard time seeing it? Personally, I can only see the
drawbacks;

 * Building druntime and phobos might be difficult with a d-based buildtool
 * The build-tool itself will need bootstrapping. A user that wants to
test some D-project, will first have to aquire (build) and install
some D-compiler with custom tools. Then install druntime with another
custom build-system. Then Phobos. Then drake. And THEN, the
application/library he/she was interested in. Shortening this path is
IMHO REALLY important to see more D adoption. From my personal
experience, convincing developers and testers to fight through this
path is HARD.
 * Cross-language builds (project with bindings), and builds with
external targets might be more difficult than need be, if the "2nd"
language is not supported by drake.
 * Verbose build-script is IMHO a _really_ undesireable trait.
 * How soon will I as a developer be able to "just build" a D-binding
to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
Gentoo, be able to count on this working in his/her envrironment too?
 * Non-compilation actions will have to be reimplemented; document
generation, test execution, install-tasks following OS-specific
install procedures (XDG-guidelines etc.), ...

IMHO, it sounds like a case of the NIH-syndrome, but I might be
missing something obvious?