December 14, 2012
One thing that I think would be really awesome when this is all rolling, is attach a system that does nightly builds of the dev line every evening. I've often had to pester Walter to produce a new build for us when a critical bug/feature was fixed.


December 14, 2012
On 12/14/12, Manu <turkeyman@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?
December 14, 2012
On 2012-12-14 13:15, Andrej Mitrovic wrote:

> Why waste Walter's time when building is as simple as calling make?

Agree. And with DVM it's just one command, after all repositories are updated, instead of calling "make" three times.

https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg
December 14, 2012
On Friday, 14 December 2012 at 12:15:28 UTC, Andrej Mitrovic wrote:
> On 12/14/12, Manu <turkeyman@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.
December 14, 2012
On Friday, 14 December 2012 at 12:56:42 UTC, Jacob Carlborg wrote:
> On 2012-12-14 13:15, Andrej Mitrovic wrote:
>
>> Why waste Walter's time when building is as simple as calling make?
>
> Agree. And with DVM it's just one command, after all repositories are updated, instead of calling "make" three times.
>
> https://github.com/jacob-carlborg/dvm

Just saw after posting. The description looks great. So, this is what D developers are using? Good stuff. Thanks.
December 14, 2012
On 14 December 2012 13:07, Dan <dbdavidson@yahoo.com> wrote:

> On Friday, 14 December 2012 at 12:15:28 UTC, Andrej Mitrovic wrote:
>
>> On 12/14/12, Manu <turkeyman@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.
>

Thank you.


December 14, 2012
On Fri, Dec 14, 2012 at 02:07:40PM +0100, Dan wrote:
[...]
> 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.
[...]

http://wiki.dlang.org/Building_DMD


T

-- 
War doesn't prove who's right, just who's left. -- BSD Games' Fortune
December 14, 2012
On Fri, Dec 14, 2012 at 06:29:50AM -0800, H. S. Teoh wrote:
> On Fri, Dec 14, 2012 at 02:07:40PM +0100, Dan wrote:
> [...]
> > 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.
> [...]
> 
> http://wiki.dlang.org/Building_DMD
[...]

Also, a more general guide to contributing to D is here:

	http://wiki.dlang.org/Get_involved

(As this is a wiki, if you find any errors/omissions please edit and
improve the page.)


T

-- 
Study gravitation, it's a field with a lot of potential.
December 14, 2012
On 2012-12-14 14:10, Dan wrote:

> Just saw after posting. The description looks great. So, this is what D
> developers are using? Good stuff. Thanks.

At least some are using it. Not the whole community. The latest release has 20 downloads across Linux, Windows and Mac OS X.

https://github.com/jacob-carlborg/dvm/downloads

-- 
/Jacob Carlborg
December 14, 2012
On Mon, Dec 10, 2012 at 06:41:25PM -0500, Andrei Alexandrescu wrote:
> Hello all,
> 
> Walter and I have had a long discussion following his trip to Australia. Following the current sprint for Win64 (which we all, I think, agree was long overdue and had to be done), the main area we need to work on (as I'm sure many would agree) is improving our process, in particular the approach to releasing the compiler and standard library.
> 
> Walter has delegated me to lead this effort, and agreed to obey with whatever process comes forward as long as it's reasonably clear and simple.
> 
> In turn, I'll be collecting thoughts and opinions in this thread, distilled from previous discussions. We should develop a few simple git scripts (such as git-start-new-feature or git-start-bugfix etc) supported by an equally simple piece of documentation describing how to start a new release, fix a bug, experiment with a new feature, and such.
> 
> (One piece that has been brought forward is http://nvie.com/posts/a-successful-git-branching-model/ - something to keep in mind.)
> 
> Please chime in with ideas and thoughts.
[...]

Hi Andrei,

A number of us have put up a draft of a proposed release process on the wiki, based on some of the things discussed in this thread.

	http://wiki.dlang.org/Release_Process

It would be *very* helpful if you could chime in with some comments from your POV as one of the core developers (in fact, it would be very good if we can have some input from _any_ of the core devs):

	http://wiki.dlang.org/Talk:Release_Process

Right now we think we have some good ideas going, but we don't want to go too far afield without any input from the core devs, since they are the ones (mainly) who will be implementing this process.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel