I'm leaving libc++abi unupdated for now, because it depends on a newer
libc++ than Chromium has managed to update to just yet. (It looks like
Chromium is, for now, manually passing -D_LIBCPP_CONSTINIT=constinit.)
Probably easier to pick that up when the dust settles.
(When that happens, libc++abi will need to be built as C++20, but that's
fine because this is only used on bots.)
Change-Id: I2b7ae62b618b0e09863b4b38548be1b937fbe0d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52646
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
VS 2017 was released in March 2017, five years ago now. This means VS
2015 is now past our support window.
This will make the unmarked and "vs2017" configs in CI/CQ do the same
thing. I'll follow up with a separate CL in infra/config to switch the
test VS 2019 instead.
Update-Note: BoringSSL may no longer build with VS 2015. Consumers
should upgrade to the latest Visual Studio release. VS 2017 or later is
required.
Change-Id: I477759deb95a27efe132de76d9ed103826110df0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52085
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We haven't done this in a while. This also tests more codepaths in
in the previous Python 3 update.
libc++ required a few more build tweaks. Also the CMake update was
necessary to update the NDK. Older CMake cannot detect CMAKE_LINKER
in the newer NDK.
Change-Id: I59ab1c6b074b805dd4b8a6ab596c4cf469d5bfa9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50167
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In doing so, I think this fixes a bug on Windows where extract.py was
digesting the archive in text mode. (Doesn't particularly matter, though
by using the correct digest, we will end up re-extracting the files
once.)
Change-Id: Ia7effe5f9c228c1a702cba8e6380975b59261808
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50166
Reviewed-by: Adam Langley <agl@google.com>
These are ultimately just the upstream tarballs, but it's one less
ad-hoc script to maintain.
Change-Id: Ia93a7a9d4944d482e4e4137587998790e8e59294
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45784
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Newer versions of CMake have some fix for default libraries on
Windows/ARM64. (Not sure exactly what version, but the latest CMake does
seem to work.)
While trying to update the others, it turns out my workstation no longer
makes CMake builds compatible with the builders. It's also tedious that
updating CMake requires making builds myself. Fortunately, Chrome infra
is maintains some packages of third-party software in CIPD.
However, they don't make Windows CMake builds (filed
https://crbug.com/1180257 to request them), and they're stuck on 3.13.x
(blocked on https://crbug.com/1176531).
So, this CL switches to CIPD for Mac/Linux, with the latest version they
have available. It sticks with the old method (uploading copies of
upstream's packages) for Windows and grabs the latest version. When both
of the bugs above are fixed, hopefully things will be more uniform.
Change-Id: I710091fc60594165738a893b2be73cdcef54dfe2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45764
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I've left libc++ and Android tools for now. libc++ is running into
https://crbug.com/1166707. I'm not sure what's wrong with the Android
tools. (CMAKE_LINKER isn't defined for some reason, but it's defined on
my machine.)
We'll also want to update the builders before the NDK anyway. The new
NDK now defaults to ANDROID_ARM_NEON=TRUE.
Change-Id: I1c0fbc3e26368c04d31464477a51e04209aec7ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45544
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>
As of
https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225,
we no longer test on Yasm. Yasm hasn't seen a release for over six years
now and is missing support for newer x86 instructions.
This removes the remnants of support for Yasm on the CI. It also removes
the Yasm support we patched into x86nasm.pl, which removes a now
unnecessary divergence from upstream.
Update-Note: If a x86 Windows asm build breaks, switch from Yasm to
NASM. We're also no longer testing NASM on x86_64 Windows, but there
wasn't any patch to revert.
Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564
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