In trying to figure out an ARM64 builder issue, I tried VS2019. That
didn't fix the ARM64 issue, but it did reveal that I ported over some of
the logic from Chromium wrong. For "new-style" paths, the toolchain
directory should be toolchain_data['path'], not the parent directory of
win_sdk.
(The latest VS2019 package in Chromium puts win_sdk a few directories
down from the toolchain root.)
This CL should be a no-op for now because all our current toolchains use
Chromium's "old-style" win_sdk-relative paths.
Change-Id: I8ad7784abb479d1ede3995a44433e57448e8debf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45744
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This lets the builders pass it in via gclient_vars. Once this lands,
I'll make the builders fill it in, at which point we can remove the
magic 'env' value and the logic in the recipe.
Change-Id: Idfc4db3e4cdecf62eacbb2925fd545e1a76b2c79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Chromium's VS toolchains now maintain JSON files with the expected
environment, so we don't need to pull in gyp to figure out the batch
file to run. This drops a long obsolete dependency and will make it
possible to handle other VS architectures. (gyp internally only handled
x86 and x64.)
Also trim away the logic in vs_toolchain.py to account for
non-depot_tools toolchains. Unlike Chromium, we don't use these scripts
outside of CI/CQ.
Change-Id: I2c9fddac52eef7b4895731d78c637fdcf9c85033
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43504
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Adam Langley