| commit | e2d7f2d625257b2c250ea2f18d3f832add5b43bf | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Mar 20 09:56:14 2024 +1000 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Apr 26 22:19:48 2024 +0000 |
| tree | a31ca72702b1c2166dd43084991d0c22ba6f0c54 | |
| parent | 765751395cf12e5842145d56ec339a1a07a1ea53 [diff] |
Add a standalone Bazel build Now that we can generate build files, we can actually maintain a Bazel build in HEAD, without synthesizing a separate "-with-bazel" branch. (Though we'll still need both for a transition, and until all the other build modes have migrated.) Note this has a slightly different directory structure than the old -with-bazel branch. But the targets are the same and #include <openssl/whatever.h> still works, so hopefully it's compatible. For now, I'm only setting this up with the new bzlmod scheme. Also since pulling in googletest is much less tedious with bzlmod, I've wired up tests and everything. https://bazel.build/external/overview#bzlmod To build, run commands like: bazelisk build ... bazelisk test ... bazelisk run :bssl The thinking is we can also go add this to CI and whatnot. This is also intended to replace the boringssl module in the bazel-central-registry which someone else set up already. To ease the transition, I've seeded the compatibility_level value with theirs. (I think we want to never bump it. Although we don't do SemVer, I think bzlmod's MVS version selection scheme is generally reasonable. Bumping it just introduces hiccups into the update process where projects need to coordinate updates, and we do not want that.) I wasn't clear on what to put in the version field in the tree, so I just went with 0.0.0-dev so we don't have to change it, but it's still vaguely analogous to the versions already in there. As part of this, I've added support for Bazel's runfiles mechanism in crypto/test/test_data.cc. This is completely undocumented and I had to figure out how it works by guessing, but I believe this is the officially supported way to make cc_test(data = ...) work? The official documentation says to use devtools_build::GetDataDependencyFilepath, but that API does not exist in the first place. I've also made it build with C++17 for now, so we can build libpki, but C++14 consumers should still be able to use this module, just not build libpki. To that end, one difference between this and the old module is that we no longer specify the C++ version in the build. From what I can tell, Bazel does *not* want libraries to set the C/C++ version and prefers it only come from the root. Unfortunately, they provide zero tools to effectively manage this. I've followed this pattern for C++ versions, as we can assume that Bazel projects are very aware of their C++ version, but I've explicitly ignored it for the C version. Projects tend not to change ABIs by C version, so it should be fine to set it internally. For context when reviewing, the unreadable MODULE.bazel.lock is automatically generated. I think the idea is that subsequent diffs will be more readable?? Bug: 542 Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@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: