commit | 7e265971c0b9188261fe6e2b7526535e95d9badc | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Wed Aug 04 14:28:55 2021 -0400 |
committer | Adam Langley <agl@google.com> | Thu Aug 05 18:37:04 2021 +0000 |
tree | edcc1e440e36ac29ac90250356ff4e9fa3e50d8c | |
parent | ead57c3004fea4dede45a4005d7789eef7d18749 [diff] |
Avoid double-expanding variables in CMake. CMake's language is rather fragile and unsound. For the most part, it is a shell script with more parentheses. That is, it simply expands command arguments into a list of strings and then evaluates it, complete with shell-style differences between "${FOO}" and ${FOO}. The if() command is special and internally also expands variables. That is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO" as a variable if it can find a variable, or a string otherwise. In addition to getting very confused on typos, it means that if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange things if BAR is a variable. CMP0054 patches this (which we set by minimum version) so that if() only expands if the token was unquoted. This fixes if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR") continues to double-expand FOO. We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear which is the canonical spelling at this point, but CMake own files (mostly) use FOO, as do most of our lines, so I've standardized on that. It's a little unsatisfying if we typo a variable, but I suppose ${FOO} also silently ignores unset variables. Bug: 423 Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705 Reviewed-by: Adam Langley <agl@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: