Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-13 03:02, Nick Sabalausky wrote:
> The recent discussions about package managers and buildsystems has prompted
> me to get off my ass (or rather, *on* my ass as per how programming is
> usually performed...) and start on the D-based rake-inspired buildtool I've
> been meaning to make for awhile now. It's not actually usable yet, but
> there's a sample drakefile demonstrating everything, and it does actually
> compile and run (but just doesn't build the dependency tree or actually run
> any of the build steps). *Should* work on Posix, but I only tested on
> Windows, so I may have fucked up the Posix version...
>
> Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
> really know what else to call it ("Duck", maybe?) Like dake, it's inspired
> by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
> Ruby, which was my #1 reason for making a Rake alternative.
>
> Before I go implemeting everything, I'd like to get input on it. Is it
> something that could be a major D tool?
>
> Overview of Drake and links to all the code are here:
>
> https://bitbucket.org/Abscissa256/drake/wiki/Home

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. But instead of starting a 
debate between Ruby and D I'm going to give you a few suggestions and 
comments instead.

The minimal drakefile doesn't look that minimal. This is the idea I have 
for a minimal build script file:

target("main.d"); // builds "main.d" as an executable

Or:

target("foobar"); // builds the directory "foobar" as a library

DSSS did this very good.

Now looking in the drakefile.d. You have targets and tasks all over the 
place, almost every target has "Task" as a template parameter. Why is 
this necessary? Have one function for targets and one for tasks. Example 
from the drakefile.d:

         target!Task("upload", "all",
                 (Target t)
                 {
                         system("ftp ...");
                 }
         );

Seems this could look like this:

task("upload", "all", {
     system("ftp...");
}); // if D just could get a better looking delegate syntax

"getDCompiler" seems unnecessary, both ldc and gdc have a dmd compatible 
wrapper, ldmd and gdmd. These wrappers takes the same flags as dmd and 
translate them to the correct "native" flags.

The "drakfile" function seems unnecessary. I would use a string import 
(or what it's called), importing the whole build script into a method in 
a class. All code in the "drakefile" function would instead be at top level.

Most of the functions called in the build script should be instance 
methods, this will allow to use threading, possible invoke multiple 
targets/tasks simultaneously and running several build scripts 
simultaneously.

I see installation related code in the build script. I think a package 
manager should be responsible for that. A build tool should deal with 
single files and a package manager should deal with packages (of files).

-- 
/Jacob Carlborg