This is designed to be the minimal infrastructure required to support
using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen
is used to generate Rust bindings in lockstep with the rest of the
build. `rust-openssl` can consume these generated bindings with minimal
changes.
Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The gclient-managed files usually go in .gitignore. I think without it,
we have to redownload it all the time on the bots? Though this also
makes my git status cleaner.
Change-Id: Ic9bac6796bd3dcdea5039bcac39e853d9f12906b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46824
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>
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>
Benjamin Brittain
David Benjamin
Adam Langley