Update windows binary links

[ihnorton]

cc: @vtjnash

[vtjnash]

I'm not familiar with archive.org as a file host, so I can't say whether that is a factor. However, can you verify the following, to make sure we don't introduce other regressions:

• built from clean checkout
  [No, but I will rebuild. Would be nice to have a way to freeze the libs, or at least LLVM. this takes forever.]
• Make.user contains override XC_HOST = i686-w64-mingw32 (or equivalent for win64) and nothing else
  [also contains DEFAULT_REPL, as per instructions]
• follows naming convention julia-[version]-[git hash]-[arch].exe, or such
  [will update after rebuild.]
• download link is permanent (e.g. if someone sends a link to this in 1-2 years, it'll still be around)
  [That is the goal of archive.org]
• contains files from make win-extras target, including 7z, libexpat, zlib1, and PortableGit (updated as needed, since upstream opensuse build service has bumped their build versions)
  [yes, and updated]
• built on linux (not windows, since the make dist target is slightly incomplete)

[ihnorton]

Comments inline. Also, I am hitting this bug ... which doesn't seem to effect anything in minimal use.

[vtjnash]

JuliaLang/julia#4213 is annoying, but not important.

DEFAULT_REPL is fine to include in Make.user, since it only affects the local environment. almost anything else (except comments) would affect the build and make it difficult to reproduce.

I require it to be a clean checkout because I have made modifications to LLVM or other dependencies in almost every build this summer (or about every month). plus, I usually have various debug copies of libraries hanging around. when I release something, I want to know that it is actually including the most recent work. fortunately for my work, I do everything on the 80-core julia machine, so a complete rebuild of both binaries takes < 10 minutes.
note: git clean -fdx is NOT sufficient, unless you also take care to delete the git submodules

it'll be good to have a second developer familiar with publishing binaries :) thanks.

naming convention can certainly be up for discussion, but the name of the output file needs to at least be modified to specify windows and 0.2pre

[ihnorton]

Well, the (separate 32/64) build directories were clean 3 days ago and I haven't done anything except fetch & rebase. If you are ok with that then I will update and merge after updating the file names. Otherwise I'll run the build overnight.

[vtjnash]

that should be fine. i don't think any of the dependencies changed in that duration. generally i have let some minor fixes apply after the build, especially when i know they are just julia or packaging related.

[ihnorton]

Merged with new links for completely-clean-from-scratch binaries including the recent Pkg updates. Both the 32 & 64 bit versions were tested with install of IJulia+PyPlot and functionality thereof.