Use the system python on the windows bots

Wow this stuff sucks

Author: alexcrichton

master/master.cfg

@@ -701,19 +701,55 @@ class CommandEnv(object):
         if "buildername" in props:
             win32toolchain = r"c:\mingw-w64\i686-4.9.1-win32-dwarf-rt_v3-rev1\mingw32\bin"
             win64toolchain = r"c:\mingw-w64\x86_64-4.9.1-win32-seh-rt_v3-rev1\mingw64\bin"
+            python = r"c:\Python27"
+            mingw32 = r"c:\msys64\mingw32\bin;c:\msys64\usr\bin"
+            mingw64 = r"c:\msys64\mingw64\bin;c:\msys64\usr\bin"
             name = props["buildername"]
 
             # This is required to trigger certain workarounds done
             # slave-side by buildbot. In particular omitting the PWD
             # variable with an unmangled pathname.
+            #
+            # Note that the PATH management here is very particular, notably:
+            #
+            # * The gcc toolchain is first in PATH. We use a custom toolchain
+            #   rather than one installed by MinGW for a few reasons. We're
+            #   going to be shipping rustc binaries produced by this toolchain,
+            #   notably LLVM is compiled and will require libstdc++-6.dll
+            #   somehow. We want to use the win32 threading model as it doesn't
+            #   have an extra dependency, and the MinGW default toolchains all
+            #   have the pthread threading model. Also LLVM will segfault at
+            #   runtime if compiled by gcc 5+ currently, so we need to stick
+            #   back to 4.9.1 ... Not fun.
+            #
+            # * Next up is the system python we have installed. The MinGW python
+            #   is super weird in a few ways. First, it will implicitly insert
+            #   an entry in PATH to `/mingw32/bin` *first* whenever it runs, so
+            #   if a program relies on the order of PATH (like make-win-dist.py)
+            #   then we'll do the wrong thing. Second, the LLVM cmake requires
+            #   python, and it requires it to basically not worry about
+            #   msys-vs-windows paths, and the MinGW python likes to take
+            #   control of paths quickly. To complicate matters, there are
+            #   **two** python installations in MinGW, both of which end up just
+            #   being totally wrong for our use case. As a result we just
+            #   installed a local copy of python and called it a day.
+            #
+            # * Finally we add the mingw paths and then the system PATH to
+            #   ensure that we can find all the necessary tools as part of the
+            #   build.
+            #
+            # Note that MSVC and MinGW share this same block. MSVC just won't
+            # use the gcc toolchain and in theory doesn't need the MinGW
+            # programs, but currently we use `make` everywhere so it definitely
+            # needs them...
             if "win-msvc-32" in name or "win-gnu-32" in name:
                 env["MACHTYPE"] = "i686-pc-win32"
                 env["MSYSTEM"] = "MINGW32"
-                env["PATH"] = win32toolchain + ";c:\\msys64\\mingw32\\bin;c:\\msys64\\usr\\bin;${PATH}"
+                env["PATH"] = ';'.join([win32toolchain, python, mingw32, '${PATH}'])
             if "win-msvc-64" in name or "win-gnu-64" in name:
                 env["MACHTYPE"] = "x86_64-pc-win32"
                 env["MSYSTEM"] = "MINGW64"
-                env["PATH"] = win64toolchain + ";c:\\msys64\\mingw64\\bin;c:\\msys64\\usr\\bin;${PATH}"
+                env["PATH"] = ';'.join([win64toolchain, python, mingw64, '${PATH}'])
 
             if "msvc" in props["buildername"]:
                 env["MSVC"] = "1"