| commit | 26669ff930a1898c77c3415e68acc97c1ef495f2 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Apr 21 15:12:24 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Apr 26 15:06:18 2023 +0000 |
| tree | 6e3a00d09db394f0726e5cc32e68d517f250d19a | |
| parent | b352546be44551f5aabc428ac4d0cc161cd1b2ec [diff] |
Don't copy all of bssl-sys into the CMake build directory Instead, just have it look for the files it needs via a BORINGSSL_BUILD_DIR environment variable. This avoids hardcoding "../../build" anywhere that cannot be easily overriden by the user. Although this puts logic in a build.rs file, which is problematic for repositories with more coherent build stories like Android or Chromium, those are already driving the bindgen and link process themselves, without calling CMake. I.e. this file should already only be used for standalone development and testing and not directly impact them. (Though we'd like to keep it vaguely analogous to better predict without a change will impact downstream folks.) For now, I've kept bindgen generated from CMake, mostly in anticipation of using the inline functions feature. Building the synthesized C file from CMake seems less of a headache than Cargo. Additionally, calling bindgen from the command-line is closer to how those consumers will do it, so this forces us to stick to bindgen invocations that can be expressed via command-line arguments. (E.g. the mess that is regexes and escaping.) As part of this, I've removed the messy "find the first matching wrapper file" behavior in build.rs. Instead, it knows the expected TARGET and just finds the file with matching name. This means we'll be stricter about matching the two. (Otherwise there's no point in naming it by target name anyway.) Fixed: 598 Change-Id: I07fa74f7e5f5f008d6f0ceec648a2378df7d317a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59105 Reviewed-by: Matthew Maurer <mmaurer@google.com> Reviewed-by: Nabil Wadih <nwadih@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: