src/ci/azure-pipelines/steps/install-windows-build-deps.yml

steps:
# We use the WIX toolset to create combined installers for Windows, and these
# binaries are downloaded from
# https://github.com/wixtoolset/wix3 originally
- bash: |
    set -e
    curl -O https://rust-lang-ci-mirrors.s3-us-west-1.amazonaws.com/rustc/wix311-binaries.zip
    echo "##vso[task.setvariable variable=WIX]`pwd`/wix"
    mkdir -p wix/bin
    cd wix/bin
    7z x ../../wix311-binaries.zip
  displayName: Install wix
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

# We use InnoSetup and its `iscc` program to also create combined installers.
# Honestly at this point WIX above and `iscc` are just holdovers from
# oh-so-long-ago and are required for creating installers on Windows. I think
# one is MSI installers and one is EXE, but they're not used so frequently at
# this point anyway so perhaps it's a wash!
- script: |
    echo ##vso[task.prependpath]C:\Program Files (x86)\Inno Setup 5
    curl.exe -o is-install.exe https://rust-lang-ci-mirrors.s3-us-west-1.amazonaws.com/rustc/2017-08-22-is.exe
    is-install.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-
  displayName: Install InnoSetup
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

# We've had issues with the default drive in use running out of space during a
# build, and it looks like the `C:` drive has more space than the default `D:`
# drive. We should probably confirm this with the azure pipelines team at some
# point, but this seems to fix our "disk space full" problems.
- script: |
    mkdir c:\MORE_SPACE
    mklink /J build c:\MORE_SPACE
  displayName: "Ensure build happens on C:/ instead of D:/"
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

- bash: git config --replace-all --global core.autocrlf false
  displayName: "Disable git automatic line ending conversion (on C:/)"

# Download and install MSYS2, needed primarily for the test suite (run-make) but
# also used by the MinGW toolchain for assembling things.
#
# FIXME: we should probe the default azure image and see if we can use the MSYS2
# toolchain there. (if there's even one there). For now though this gets the job
# done.
- bash: |
    set -e
    choco install msys2 --params="/InstallDir:$(System.Workfolder)/msys2 /NoPath" -y --no-progress
    echo "##vso[task.prependpath]$(System.Workfolder)/msys2/usr/bin"
    mkdir -p "$(System.Workfolder)/msys2/home/$USERNAME"
  displayName: Install msys2
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

- bash: pacman -S --noconfirm --needed base-devel ca-certificates make diffutils tar
  displayName: Install msys2 base deps
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

# If we need to download a custom MinGW, do so here and set the path
# appropriately.
#
# Here we also do a pretty heinous thing which is to mangle the MinGW
# installation we just downloaded. Currently, as of this writing, we're using
# MinGW-w64 builds of gcc, and that's currently at 6.3.0. We use 6.3.0 as it
# appears to be the first version which contains a fix for #40546, builds
# randomly failing during LLVM due to ar.exe/ranlib.exe failures.
#
# Unfortunately, though, 6.3.0 *also* is the first version of MinGW-w64 builds
# to contain a regression in gdb (#40184). As a result if we were to use the
# gdb provided (7.11.1) then we would fail all debuginfo tests.
#
# In order to fix spurious failures (pretty high priority) we use 6.3.0. To
# avoid disabling gdb tests we download an *old* version of gdb, specifically
# that found inside the 6.2.0 distribution. We then overwrite the 6.3.0 gdb
# with the 6.2.0 gdb to get tests passing.
#
# Note that we don't literally overwrite the gdb.exe binary because it appears
# to just use gdborig.exe, so that's the binary we deal with instead.
- bash: |
    set -e
    curl -o mingw.7z $MINGW_URL/$MINGW_ARCHIVE
    7z x -y mingw.7z > /dev/null
    curl -o $MINGW_DIR/bin/gdborig.exe $MINGW_URL/2017-04-20-${MSYS_BITS}bit-gdborig.exe
    echo "##vso[task.prependpath]`pwd`/$MINGW_DIR/bin"
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), ne(variables['MINGW_URL'],''))
  displayName: Download custom MinGW

# Otherwise install MinGW through `pacman`
- bash: |
    set -e
    arch=i686
    if [ "$MSYS_BITS" = "64" ]; then
      arch=x86_64
    fi
    pacman -S --noconfirm --needed mingw-w64-$arch-toolchain mingw-w64-$arch-cmake mingw-w64-$arch-gcc mingw-w64-$arch-python2
    echo "##vso[task.prependpath]$(System.Workfolder)/msys2/mingw$MSYS_BITS/bin"
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), eq(variables['MINGW_URL'],''))
  displayName: Download standard MinGW

# Make sure we use the native python interpreter instead of some msys equivalent
# one way or another. The msys interpreters seem to have weird path conversions
# baked in which break LLVM's build system one way or another, so let's use the
# native version which keeps everything as native as possible.
- bash: |
    set -e
    cp C:/Python27amd64/python.exe C:/Python27amd64/python2.7.exe
    echo "##vso[task.prependpath]C:/Python27amd64"
  displayName: Prefer the "native" Python as LLVM has trouble building with MSYS sometimes
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

# Note that this is originally from the github releases patch of Ninja
- bash: |
    set -e
    mkdir ninja
    curl -o ninja.zip https://rust-lang-ci-mirrors.s3-us-west-1.amazonaws.com/rustc/2017-03-15-ninja-win.zip
    7z x -oninja ninja.zip
    rm ninja.zip
    echo "##vso[task.setvariable variable=RUST_CONFIGURE_ARGS]$RUST_CONFIGURE_ARGS --enable-ninja"
    echo "##vso[task.prependpath]`pwd`/ninja"
  displayName: Download and install ninja
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))