Prototype buildsystem "Drake"

[Nick Sabalausky]

"Ulrik Mikaelsson" <ulrik.mikaelsson at gmail.com> wrote in message 
news:mailman.1620.1310596361.14074.digitalmars-d at puremagic.com...
> 2011/7/13 Nick Sabalausky <a at a.a>:
>> "Jacob Carlborg" <doob at me.com> wrote in message
>> news:ivke5k$2m78$1 at digitalmars.com...
>>>
>>> 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.
>>
>> Yea, D is likely to be a little more verbose than what could be done in 
>> Ruby
>> (or Python). Personally, I think that's well worth it, though. I don't 
>> know
>> how many others would agree or not.
>>
>
> Not trying to be argumentative, but what exactly do you see as the
> gains in having a D-buildtool built in D (or D-specific build-tool in
> any language, for that matter)? Seriously, I'm really asking, since
> I'm having a hard time seeing it?

Perfectly understandable question. First of all, it isn't really a 
D-specific tool, it's intended to be usable for anything (including D, of 
course). It's just that it's written in D and it uses buildscripts that are 
written in D.

As for why a new one based on D instead of just using Rake/SCons/Waf/etc., 
like Andrei said, there's the dogfooding and brand image issues. Also:

- D programmers and people working on D projects don't have to learn or 
switch to another language for their buildscripts.

- D projects don't have to be dependent on other languages or VMs. Although 
I have to say I was impressed that Jacob's Ruby-buildscript-based Dake 
avoids this problem.

- Utility functions can easily be shared between a D program and it's build 
script (for whatever that's worth, but I can imagine it could come in handy 
now and then).

- Also, I just like D a lot more than I like Ruby/Python and I think it's 
safe to assume there are probably other D users who feel the same (since 
they're D users after all).


> Personally, I can only see the
> drawbacks;
>
> * Building druntime and phobos might be difficult with a d-based buildtool

Those already use make, and I'm not sure that's really going to change.


> * The build-tool itself will need bootstrapping. A user that wants to
> test some D-project, will first have to aquire (build) and install
> some D-compiler with custom tools. Then install druntime with another
> custom build-system. Then Phobos. Then drake. And THEN, the
> application/library he/she was interested in. Shortening this path is
> IMHO REALLY important to see more D adoption. From my personal
> experience, convincing developers and testers to fight through this
> path is HARD.

It's not as complicated as you suggest. Suppose someone wants to try 
building FooApp:

Step 1: D compilers already come prebuilt, with Phobos and Druntime already 
set up. So just install DMD. Done. Or users can install DVM and then install 
DMD with "dvm install {version} && dvm use -d (version)".

Step 2: Install drake. Or, FooApp could even just include Drake. Or, FooApp 
could be installed with a package manager that sees FooApp depends on Drake 
and so auto-installs Drake first.

Step 3: Run "drake all". That invokes a trivial one-line shell/batch script 
that will automatically compile drake and the buildscript (if they're not 
already built), and then run the buildscript.

Or, when we get a good package manager, we could just offer pre-built 
versions of the package manager and then:

Step 1: Install the package manager (which might even install DMD 
automatically, possibly via DVM).

Step 2: Run "d-package-manager install FooApp". The package manager 
determines FooApp depends on DMD and Drake (and maybe DVM), and 
automatically installs all of that, then installs FooApp and invokes 
FooApp's post-install script which is "drake all", and thus builds FooApp.

Step 3: Enjoy a nice latte, because you're done.


> * Cross-language builds (project with bindings), and builds with
> external targets might be more difficult than need be, if the "2nd"
> language is not supported by drake.

One of my primary goals for Drake is that anything you can do on the command 
line can easily be done with Drake. So that amounts to pretty much any 
language. Drake doesn't require special bindings to use any particular tool 
(although bindings to abstract away the command line can be made, if 
desired)


> * Verbose build-script is IMHO a _really_ undesireable trait.

Fair enough point. It's possible I might not be able to get it quite as 
terse as some systems, but I am trying my best to minimize verbosity. I 
think the cross-platform extensions like "foo".exe are a good example of 
that. It uses the trickery of module-level "properties" combined with UFCS 
to achieve what I think may be the simplest possible D syntax for 
cross-platform file extensions (at least without getting too crazy).


> * How soon will I as a developer be able to "just build" a D-binding
> to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
> Gentoo, be able to count on this working in his/her envrironment too?

TBH, I'm not exactly well-versed in linking C++ and D. Actually, I've never 
even looked into it, let along done it...

Basically, if you know how to do it on the command line, then you can "just 
do it" in Drake. If you're looking for something more magical, then I'd say 
"Whenever someone writes an abstraction for it".


> * Non-compilation actions will have to be reimplemented; document
> generation, test execution, install-tasks following OS-specific
> install procedures (XDG-guidelines etc.), ...
>

Not really sure what you mean here.


> IMHO, it sounds like a case of the NIH-syndrome, but I might be
> missing something obvious?

I suppose someone could argue that it's NIH, technically speaking. 
(Personally, I feel that anti-NIH sentiment is overrated.) But I think it's 
worthwhile just to be able to write buildscripts in D. After all, nobody 
really *has* to use D for anything. They can just write their apps in C, 
C++, Java, Ruby, Python, etc. But a growing number of people use D because 
they like it and feel it provides certain benefits. So I guess I'd say: Why 
shouldn't we be able to write buildscripts in D and make use of a helpful 
framework/library to do it?