Prototype buildsystem "Drake"

[Nick Sabalausky]

"jdrewsen" <jdrewsen at nospam.com> wrote in message 
news:ivl1gp$o1v$1 at digitalmars.com...
>
> 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.
>

I think that's an excellent point. Only thing: Is "dbuild" already taken? 
Also I'd hate to claim that name if nobody ended up liking it ;)


> 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"
>

Yea, that's a fair point. But I figure I should start with general and then 
build the simple/structured on top of that, rather than trying to go the 
other way around.


> 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);
>

Thanks, definitely things to think about.

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

Hmm, yea, configure didn't even occur to me. I think it could acually be 
done as just another File target that everything else depends on. Only thing 
is then you'd have to save/load the configuration file manually, so maybe 
there should be some convenience mechnism for that (Maybe utilizing Jacob's 
Orange serialization library once that rewrite is done? Or maybe that would 
be overkill? Is there some INI-file util, or am I just imagining that?)