Next focus: PROCESS

[Dan]

On Friday, 14 December 2012 at 12:15:28 UTC, Andrej Mitrovic 
wrote:
> On 12/14/12, Manu <turkeyman at gmail.com> wrote:
>> I've often had to pester Walter to produce a new build for us 
>> when a
>> critical bug/feature was fixed.
>>
>
> Why waste Walter's time when building is as simple as calling 
> make?

His point was he clearly wants *not* to waste Walter's time.

In the discussions of build system one thread was about using 
Ruby. A comment was why not just use D to script it, you can do 
everything in D that you can from ruby (or shell)? I wrote a 
small script to see how cumbersome it would be to download and 
build D with that approach: one piece grabs latest source 
(phobos, runtime, dmd, tools), one builds it. 
http://pastebin.com/CC7DvZuJ

It ain't pretty and tailored to linux. I don't know how D 
developers set up their environment - a technote may exist 
somewhere? The focus in this thread is on release process which 
is critical, but an addition to wiki page on "how to get started 
as a developer on D project" might be useful. I don't think it is 
that complex to build D, but for me it was not as simple as just 
calling make because you have to get the prereqs, know things 
like phobos inludes the runtime, so build runtime before phobos, 
and if you want release and debug builds you should have separate 
folders since they build in place.
I also made a small change local to posix.mak, to be able to 
build debug.

------
-GFLAGS = $(WARNINGS) -D__pascal= -fno-exceptions -O2
+ifneq (x,x$(DEBUG))
+	GFLAGS = $(WARNINGS) -D__pascal= -fno-exceptions -g -DDEBUG=1 
-DUNITTEST $(COV)
+else
+	GFLAGS = $(WARNINGS) -D__pascal= -fno-exceptions -O2
+endif
------

This may all be bad advice, since I only did it to see if I could 
step into associative array code to track down a bug and I don't 
know the good D dev setup for linux.

Any ideas that push toward continuous build/integration/test are 
the right direction.