On 5/29/13 1:33 PM, Martin Nowak wrote:
> On 05/29/2013 12:12 AM, Andrei Alexandrescu wrote:
>> How do I get/build the changelog?
> https://github.com/D-Programming-Language/tools/blob/master/changed.d

Great, thanks. I see http://dlang.org/changelog.html already has a changelog in place, but I didn't generate it. Who did?

Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/29/13, Martin Nowak <code@dawg.eu> wrote:
> On 05/29/2013 12:12 AM, Andrei Alexandrescu wrote:
>> How do I get/build the changelog?
> https://github.com/D-Programming-Language/tools/blob/master/changed.d

Note: The changelog is already in the dlang.org/changelog.dd file. The
tool above lists bugzilla issues, but I've already insterted those
into the changelog.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Alright, thanks much!

Aside from the version still showing "-devel", do we have any issues preventing us from announcing the release?


Andrei

On 5/29/13 3:17 PM, Andrej Mitrovic wrote:
> On 5/29/13, Martin Nowak<code@dawg.eu>  wrote:
>> On 05/29/2013 12:12 AM, Andrei Alexandrescu wrote:
>>> How do I get/build the changelog?
>> https://github.com/D-Programming-Language/tools/blob/master/changed.d
>
> Note: The changelog is already in the dlang.org/changelog.dd file. The
> tool above lists bugzilla issues, but I've already insterted those
> into the changelog.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Hm, it looks there is no information in ChangeLog for .so support for linux, was it dropped from release?

Anyway, great thanks!


2013/5/29 Andrei Alexandrescu <andrei@erdani.com>

> Alright, thanks much!
>
> Aside from the version still showing "-devel", do we have any issues preventing us from announcing the release?
>
>
> Andrei
>
>
> On 5/29/13 3:17 PM, Andrej Mitrovic wrote:
>
>> On 5/29/13, Martin Nowak<code@dawg.eu>  wrote:
>>
>>> On 05/29/2013 12:12 AM, Andrei Alexandrescu wrote:
>>>
>>>> How do I get/build the changelog?
>>>>
>>> https://github.com/D-**Programming-Language/tools/** blob/master/changed.d<https://github.com/D-Programming-Language/tools/blob/master/changed.d>
>>>
>>
>> Note: The changelog is already in the dlang.org/changelog.dd file. The
>> tool above lists bugzilla issues, but I've already insterted those
>> into the changelog.
>> ______________________________**_________________
>> dmd-beta mailing list
>> dmd-beta@puremagic.com
>> http://lists.puremagic.com/**mailman/listinfo/dmd-beta<http://lists.puremagic.com/mailman/listinfo/dmd-beta>
>>
> ______________________________**_________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-beta<http://lists.puremagic.com/mailman/listinfo/dmd-beta>
>

On 5/29/13 4:32 PM, Oleg Kuporosov wrote:
> Hm, it looks there is no information in ChangeLog for .so support for
> linux, was it dropped from release?

Should be there!!!

Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

http://downloads.dlang.org.s3.amazonaws.com/releases/2013/dmd.2.063.zip ?
I'm still not sure how to build dmd without irstate.h in the zip file.

The new change log is really impressive with all the examples and explanations!

Best regards,
Marco Leise
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/29/13, Oleg Kuporosov <oleg.kuporosov@gmail.com> wrote:
> Hm, it looks there is no information in ChangeLog for .so support for linux

I don't know the state of this, so I didn't write anything in.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Wed, May 29, 2013 at 10:52 PM, Andrei Alexandrescu <andrei@erdani.com> wrote:
> On 5/29/13 4:32 PM, Oleg Kuporosov wrote:
>>
>> Hm, it looks there is no information in ChangeLog for .so support for linux, was it dropped from release?
> Should be there!!!

Related: http://forum.dlang.org/post/snrykwozsimstuewzfnl@forum.dlang.org

David
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/28/13 9:26 PM, Nick Sabalausky wrote:
> On Tue, 28 May 2013 18:19:57 -0700
> Brad Roberts <braddr@puremagic.com> wrote:
>>
>> Ignore what may or may not exist outside the current make files.
>> Just start with what exists in them.  Soon after there are workable
>> targets to the existing makefiles, I'll get the auto-tester to
>> execute them and upload the results to s3 and make them public.
>>
>> I really don't think the zip/tarball creation steps should be a
>> separate script.  A while back I started putting together a proof of
>> concept / strawman version of what I was thinking.  They're likely
>> somewhat bitrotten, but look at my account on github in the dmd,
>> druntime, and phobos repos.  There's an 'install' branch for each of
>> them with a commit or two to each.
>>
>> I stopped when I git the documentation as the build systems for them
>> are absurdly complex and convoluted.  Additionally, the tools stuff
>> needs work, though its been ages since I last looked at them.
>>
>
> While that may be a feasible approach, IMO I think it's worth
> minimizing the amount of work D's infrastructure needs to do in
> shell, batch and makefile scripting. Compared to D itself, those tend
> to be less portable (most notably the Win/Posix rift), more difficult to
> write/maintain, and less graceful with unexpected failures. Plus
> there's the increased dogfooding and the whole "self-hosted bragging
> rights" thing that some people value.

Except that the build infrastructure already exists and incrementing on top of it is a reasonably small task.  Ripping out what we have and changing it fundamentally isn't.  That there's a single make file for all but windows is a pretty good demonstration that it _is_ fairly portable.  The primary (if not only) reason we don't use a single make file is that the make executable we have on windows came from the dmc world and is awful.  Replacing it with gnu make would help a ton.

I'll give a much more practical response now:  As a new make target, getting it added to the auto-tester would be a small quick job.  Getting it written, reviewed, and pulled would be much easier than a month of discussion around what the replacement should look like, etc.  I'd prefer to have automated builds _nowish_ not laterish.

In fact, I suspect that what I whipped up and pointed to above would get us nightly builds w/in a day or two and finishing up the docs and tools could be done later.

In further fact, that's what I'm going to do tonight.. at least get a pull request generated to start the bike-shedding.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Wed, 29 May 2013 21:59:07 -0700
Brad Roberts <braddr@puremagic.com> wrote:

> On 5/28/13 9:26 PM, Nick Sabalausky wrote:
> > On Tue, 28 May 2013 18:19:57 -0700
> > Brad Roberts <braddr@puremagic.com> wrote:
> >>
> >> Ignore what may or may not exist outside the current make files. Just start with what exists in them.  Soon after there are workable targets to the existing makefiles, I'll get the auto-tester to execute them and upload the results to s3 and make them public.
> >>
> >> I really don't think the zip/tarball creation steps should be a separate script.  A while back I started putting together a proof of concept / strawman version of what I was thinking.  They're likely somewhat bitrotten, but look at my account on github in the dmd, druntime, and phobos repos.  There's an 'install' branch for each of them with a commit or two to each.
> >>
> >> I stopped when I git the documentation as the build systems for them are absurdly complex and convoluted.  Additionally, the tools stuff needs work, though its been ages since I last looked at them.
> >>
> >
> > While that may be a feasible approach, IMO I think it's worth minimizing the amount of work D's infrastructure needs to do in shell, batch and makefile scripting. Compared to D itself, those tend to be less portable (most notably the Win/Posix rift), more difficult to write/maintain, and less graceful with unexpected failures. Plus there's the increased dogfooding and the whole "self-hosted bragging rights" thing that some people value.
> 
> Except that the build infrastructure already exists and incrementing on top of it is a reasonably small task.  Ripping out what we have and changing it fundamentally isn't.  That there's a single make file for all but windows is a pretty good demonstration that it _is_ fairly portable.  The primary (if not only) reason we don't use a single make file is that the make executable we have on windows came from the dmc world and is awful.  Replacing it with gnu make would help a ton.
> 

I didn't really mean to suggest replacing the existing makefile stuff with D (and my Windows bootstrapper doesn't even attempt to replace them - in fact it *uses* the makefiles <https://github.com/D-Programming-Language/installer/pull/18>).

I mainly just meant that additional functionality, such as packaging the ZIP releases, stringing together the "make -f blah.mak"'s of all the various sub-projects and copying over the needed bins from DMC, etc, and anything else we end up wanting, would be better off just doing in D instead of adding in yet more shell/makefile/batch code. And if there is any existing shell stuff that could also benefit and wouldn't be too much trouble, well then heck, may as well.

> I'll give a much more practical response now:  As a new make target, getting it added to the auto-tester would be a small quick job.

Last I checked (but maybe I'm out-of-date) the tester stuff was fairly system-specific, and my understanding was that it isn't necessarily easy for others to setup an arbitrary computer to run the test suite.

Again, I'm not suggesting that we hurry and rewrite the auto-tester in D, just that in the long run there may be value in steering various (unspecified) things that direction.

> Getting it written, reviewed, and pulled would be much easier than a month of discussion around what the replacement should look like,

Or how it should be written? ;) j/k

But again, I should emphasize: I'm not suggesting any big replacements here. I'm mainly just talking about *new* functionality, such as packaging zips or building an *entire* DMD (ie, not just the individual parts).

I do think there might be value in migrating certain existing stuff to
D, particularly little things that would be trivial to translate and
would become more manageable (like this particular file:
<https://github.com/D-Programming-Language/installer/blob/master/linux/build_all.sh>).

But nothing like replacing the "compile DMD or phobos or druntime" sections of the makefiles, or replacing the makefiles entirely, or replacing the auto-tester entirely, etc. Certainly not short-term anyway. (And really, keeping the "compile DMD or phobos or druntime" stuff *in* makefiles would be a good idea anyway to aid in bootstrapping new platforms.)

> In fact, I suspect that what I whipped up and pointed to above would get us nightly builds w/in a day or two and finishing up the docs and tools could be done later.
> 

I suppose I've been under the assumption that, right now, having any official "infrastructure" tools (such as things that involve building/packaging DMD itself) actually be written in D instead of shell/batch/etc would be a bad idea because then they would require D already be built, and therefore could conceivably lead to tricky situations (at least for anyone who isn't already familiar with all the details of going from cloning all the repos and getting a working non-release DMD).

But maybe that's a false assumption after all. For example, we don't really *need* the "generate a release ZIP" script to be runnable on a machine that doesn't already have a working DMD, do we? Probably not.

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta