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

Reply via email to