[dmd-beta] 2.063 released!

[Nick Sabalausky]

On Wed, 29 May 2013 21:59:07 -0700
Brad Roberts <braddr at 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 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 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.