Prototype buildsystem "Drake"

[Andrei Alexandrescu]

On 7/13/11 5:32 PM, Ulrik Mikaelsson wrote:
> 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)?

I think it's a matter of positioning D and eating one's dogfood. If D is 
inconceivable for the kind of tasks that Python or Ruby are adept at, 
then sure, we could and should use either. On the other hand, if we 
advocate D as a good tool for short scripts, using the competition would 
hurt its brand.

Personally I believe D is plenty adequate for short scripts, of which 
I've written a ton of. So the path of least resistance for a package 
manager or for a build tool is D, not any other language. I'd question 
much harder the decision of using another language (D is, however, not a 
competitor for the likes of bash or make).

> 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

Druntime and phobos are distributed, and only built by a small number of 
users. We should not worry about building them. Also, a tool based on 
other language would require that language's environment to be already 
available.

>   * 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.

The installation provides the adequate tools. Installing and building 
from scratch is unnecessary. A user wanting to test some project needs 
to (a) install dmd using OS-specific installation tools (which we 
already have) and (b) use the provided tools to build whatever project.

>   * 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.

This is a good advantage of generic build tools.

>   * Verbose build-script is IMHO a _really_ undesireable trait.

I don't understand this.

>   * 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?

This pretty much depends on the capabilities of the tool, which would 
have to be fairly D-specific.

>   * Non-compilation actions will have to be reimplemented; document
> generation, test execution, install-tasks following OS-specific
> install procedures (XDG-guidelines etc.), ...

Here you're conflating the capabilities of the tool with the 
capabilities of the _langauge_ used to implement the tool.

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

I see no NIH here. D is an ample language scaling up to large programs 
and down to scripts. If the question is to build a tool from scratch, D 
is the obvious choice and any other choice is just odd. It's like some 
tools I've seen (none successful) that required the competition's 
product to be installed in order to work.


Andrei