| commit | 9bbf0d97630219dcc6c528f198b8b92c2427857c | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Jun 30 13:17:03 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Jul 03 14:08:04 2023 +0000 |
| tree | 925e9808763d3e52c7c54b08d0c2c9ee8baf534b | |
| parent | 5eab868eaa5f7a975d50579182e26902441342be [diff] |
Use sources.cmake for pki and pki_test This achieves much of the same goals as https://boringssl-review.googlesource.com/c/boringssl/+/61245, but reuses the existing source.cmake parser in generate_build_files.py. There are two practical differences here: First, CMake knows that, if it sees include(sources.cmake), it should add sources.cmake as a dependency of build.ninja, and re-run cmake if source.cmake changes. It does not know this for file(STRINGS). This can be fixed with CMAKE_CONFIGURE_DEPENDS, but since we already have this, may as well use it. Second, sources.cmake wants paths rooted at the top-level BoringSSL source directory, which means we want to define the targets at the top level, rather than in subdirectories. While it will make the top-level CMakeLists.txt larger, I think this is a good move: - ./build/crypto_test --gtest_filter=... is just less annoying to type than ./build/crypto/crypto_test --gtest_filter=... - It will (eventually) mean libcrypto.a lives at build/libcrypto.a instead of build/crypto/libcrypto.a. This means we can pass a single -L parameter when building things against BoringSSL, without relying on the install target. - It aligns with the generated CMake build. I would like, long-term, to stop maintaining multiple CMake builds, and the generated one seems to have a better convention. And one that will be more disruptive to others if we change it. - Top-level-rooted paths are more convenient for generate_build_files.py to work with, because that's what we want to output. As I get further along in 542, I expect I'll move this once again, possibly to some JSON file, because I'll need my new pregenerate tool to parse it (and we'll no longer be constrained by what's easy to consume in CMake), but use this for now. Bug: 542 Change-Id: I1e8b894057264da5d7624a1fbb92f9e1198ea38e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61266 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@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: