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