Den 13-07-2011 03:02, Nick Sabalausky skrev:
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

A good start I think. The first thing that I think should be fixed is the naming.

Drake should be called dbuild
Orb should be called dpack

You read the name and you have an idea of what it does - nothing fancy.

People coming from ruby may recognize the drake name, but I guess many c++ peoply have no idea.
Orb is not derived from anything I guess.

Regarding drake itself:

I really like how general it is but at the same time miss some simplicity. "Make the common task easy and the uncommon possible"

Some steps that you could take in that direction is to predefine commonly used modes like "build", "clean" etc. And the define buildMode(), cleanMode() as builtins. That would get rid of the "immutable modes = ..." lines in simple projects.

Maybe let the wrapper that loads the drakefile insert the "import drake.all" and also wrap the "void drakefile() { ... }" around the file. Maybe that is what your have already listed on the todo?

As suggested elsewhere you could get rid of target!Task or target!File and just defined the target() and file() functions.

Also a convenience could be to just include all .d files found for an exe target if no .d files are explicitly listed.

I guess this would make it possible to have a drakefile as simple as:

task("appA".exe);


It seems to lack the configure part of the build process e.g. locate the libfoobar.a file for linking or locate a D compiler.

Thanks,
/Jonas

Reply via email to