[dmd-beta] 2.063 released!

[Brad Roberts]

On 5/28/13 9:26 PM, Nick Sabalausky wrote:
> On Tue, 28 May 2013 18:19:57 -0700
> Brad Roberts <braddr at 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.