On Wed, 29 May 2013 21:59:07 -0700 Brad Roberts <[email protected]> wrote:
> On 5/28/13 9:26 PM, Nick Sabalausky wrote: > > On Tue, 28 May 2013 18:19:57 -0700 > > Brad Roberts <[email protected]> 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 [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
