aboutsummaryrefslogtreecommitdiff
path: root/CMakeLists.txt
AgeCommit message (Collapse)AuthorFilesLines
2024-06-07Update other CI toolsDavid Benjamin1-2/+2
Change-Id: I6acff65f952a6d96df918d692c1fe8d2ae469ff7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69167 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-05-29Fix build with -Wctad-maybe-unsupportedDavid Benjamin1-0/+8
The immediate use of CTAD was actually unnecessary due to CBS implicitly converting to Span. Still, let's make Span CTAD-capable and thus remove some unnecessary MakeSpans and MakeConstSpans in libpki. I've kept them in libssl which, for now, still allows C++14. Change-Id: Iec92f520f645f86f098afb860a2129fb30c61da9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68847 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-29Make Go an optional build dependency for the CMake buildDavid Benjamin1-16/+25
Matching the various pre-generated builds, the CMake build no longer actually requires Go. The only things that need it are: - Running tests - Builds with -DFIPS=1 - Builds with the experimental symbol prefixing thing Bug: 542 Change-Id: I52bb427f54dd6e5719cfe77773e87fc394410380 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67367 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-03-23Flatten crypto/CMakeLists.txt into the top-levelDavid Benjamin1-34/+147
This avoids needing to rebase the source lists. It also means that libcrypto.a and libssl.a end up directly in the build directory, which makes it a bit easier to pass it to, say, gcc -L when testing things. That file is, alas, getting a bit large. delocate is a pretty large amount of code. I tried to abstract things into functions to toss into a cmake/delocate.cmake, but CMake is really bad at making abstractions. Bug: 542 Change-Id: I084d7a6bdd4c21ac27859b8b0c9d7a84829f2823 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67298 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-23Rework the test data storyDavid Benjamin1-21/+1
We originally embedded test data because of deficiencies in Android's build. Android had no way to specify test data with tests. That has since been resolved, and the embedding mechanism has gotten unwieldy. This unifies pki_test and crypto_test's test data story, and does so in a way that all tests can participate in. (We can now use FileTest in decrepit_test.) Update-Note: This will require some tweaks to downstream builds. We no longer emit an (unwieldy) crypto_test_data.cc file. Instead, tests will expect test data be available at the current working directory. This can be overridden with the BORINGSSL_TEST_DATA_ROOT environment variable. Callers with more complex needs can build with BORINGSSL_CUSTOM_GET_TEST_DATA and then link in an alternate implementation of this function. On the off chance some project needs it, I've kept the embed_test_data.go script around for now, but I expect we can delete it in the future. Fixed: 681 Change-Id: If181ce043e1eea3148838f1bb4db9ee4bfda0d08 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67295 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2024-03-23Move the rest of sources.cmake into util/pregenerateDavid Benjamin1-1/+0
Bug: 542 Change-Id: I23c3c5c01ae41bd98f605b34e09269a6602a2c49 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67294 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-22Check in pre-generated perlasm and error data filesDavid Benjamin1-4/+8
This adds a tool for managing pre-generated files, aligning our CMake and non-CMake builds. The plan is roughly: The source of truth for the file lists will (eventually) be build.json. This describes the build in terms of the files that we directly edit. However, we have a two-phase build. First a pregeneration step transforms some of the less convenient inputs into checked in files. Notably perlasm files get expanded. This produces an equivalent JSON structure with fewer inputs. The same tool then outputs that structure into whatever build systems we want. This initial version pre-generates err_data.c and perlasm files. I've not wired up the various build formats, except for CMake (for the CMake build to consume) and JSON (for generate_build_files.py to parse). build.json is also, for now, only a subset of the build. Later changes The upshot of all this is we no longer have a Perl build dependency! Perl is now only needed when working on BoringSSL. It nearly removes the Go one, but Go is still needed to run and (for now) build the tests. To keep the generated files up-to-date, once this lands, I'll update our CI to run `go run ./util/pregenerate -check` which asserts that all generated files are correct. From there we can land the later changes in this patch series that uses this more extensively. My eventual goal is to replace generate_build_files.py altogether and the "master-with-bazel" branch. Instead we'll just have sources.bzl, sources.gni, etc. all checked into the tree directly. And then the normal branch will just have both a CMake and Bazel build in it. Update-Note: generate_build_files.py no longer generates assembly files or err_data.c. Those are now checked into the tree directly. Bug: 542 Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-21Start making asserts constant-time tooDavid Benjamin1-2/+0
We've historically settled on treating asserts as not in scope for our constant-time goals. Production binaries are expected to be optimized builds, with debug assertions turned off. (We have a handful of assertions in perf-sensitive code that you definitely do not want to run with.) Secret data has invariants too, so it is useful to be able to write debug assertions on them. However, combined with our default CMake build being a debug build, this seems to cause some confusion with researchers sometimes. Also, if we ever get language-level constant-time support, we would need to resolve this mismatch anyway. (I assume any language support would put enough into the type system to force us to declassify any intentional branches on secret-by-data-flow bools, notably those we assert on.) So I'm inclined to just make our asserts constant-time. There are two issues around asserts, at least with our valgrind-based validation: The first is that a couple of asserts over secret data compute their condition leakily. We can just fix these. The only such ones I found were in bn_reduce_once and bn_gcd_consttime. The second is that almost every assert over secret data will be flagged as an invalid branch by valgrind. However, presuming the condition itself was computed in constant time, this branch is actually safe. If we were willing to abort the process when false, the assert is clearly publicly true. We just need to declassify the boolean to assert on it. assert(constant_time_declassify_int(expr)) is really long, so I made an internal wrapper macro declassify_assert(expr). Not sure if that's the best name. constant_time_declassify_assert(expr) is kinda long. constant_time_assert(expr) fits with the rest of that namespace, but reads as if we're somehow running an assert without branching, when the whole point is that we *are* branching and need to explicitly say it's okay to. Fixed: 339 Change-Id: Ie33b99bf9a269b11d2c48d246cc4934be7e239ff Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65467 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-20Move ssl and decrepit sources to sources.cmakeDavid Benjamin1-5/+13
Bug: 542 Change-Id: Iec0348555b988f8eb8eb24394a867e015b125c20 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67227 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-17Gate -Wframe-larger-than on Clang 13David Benjamin1-1/+13
This is a somewhat speculative fix for https://crbug.com/boringssl/709. Fixed: 709 Change-Id: I7ace65ca86048a04994fef7811527423af70e933 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67087 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-17Make ninja run_tests output less confusingDavid Benjamin1-0/+5
We say "all tests passed" but we actually mean only the unit tests. Now the output is: Running Go tests ok boringssl.googlesource.com/boringssl/ssl/test/runner/hpke (cached) ok boringssl.googlesource.com/boringssl/util/ar (cached) ok boringssl.googlesource.com/boringssl/util/fipstools/acvp/acvptool/testmodulewrapper (cached) ok boringssl.googlesource.com/boringssl/util/fipstools/delocate (cached) Running unit tests ssl_test [shard 1/10] ... pki_test [shard 8/10] All unit tests passed! Running SSL tests 0/0/5481/5481/5481 PASS ok boringssl.googlesource.com/boringssl/ssl/test/runner 21.110s all_tests.go really should be called unit_tests.go, but renaming it will probably be too annoying. Change-Id: I7ff6684221930e19152ab3400419f4e5209aaf46 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67107 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-03-11Set -Wframe-larger-than=25344 for a typical cmake clang compile.Bob Beck1-1/+1
This ensures that in the "usual" development process building and running the tests will enforce this stack limit, which is encountered in google3. This will prevent future development from adding code and tests which blow over this limit and break google3 Change-Id: If722c7029cca63eb7d1e80de4b640b84839bb020 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66867 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com>
2024-02-15Allow a C++ runtime dependency in libsslDavid Benjamin1-12/+0
I believe the original blocker, gRPC, is now cleared. While I'm here, make check_imported_libraries print all errors, rather than the first one. (Though if this sticks, we can probably remove this script. It was only needed for the C++ runtime check.) Update-Note: libssl now requires a C++ runtime, in addition to the pre-existing C++ requirement. Contact the BoringSSL team if this causes an issue. Some projects may need to switch the final link to use a C++ linker rather than a C linker. Change-Id: I94808bf1dad6695ef334e262f3d2426caab0520e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66288 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-02-09Add functions to convert from Span<const uint8> and std::string_viewDavid Benjamin1-1/+5
These can replace the current der::Input-specific string_view methods. I converted many of the uses within the library, but we should take a pass over the library and turn many of the std::strings into std::vector<uint8_t>. On MSVC, we have to pass /Zc:__cplusplus for __cplusplus to be set correctly. For now, I'm going to try just adding the flag, but if pki gets used in more places before we bump our minimum to C++17, we may want to start looking at _MSVC_LANG instead. There are actually a few places outside of pki that could use this, but we sadly can't use them until we require C++17 across the board. Bug: 661 Change-Id: I1002d9f2e1e4a2592760e8938560894d42a9b58c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65908 Reviewed-by: Bob Beck <bbe@google.com> Reviewed-by: Matt Mueller <mattm@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-01-26Remove remnants of the old Android CMake toolchainDavid Benjamin1-9/+1
The PATH-related workarounds for the old third-party Android toolchain don't seem to apply to the official NDK one, so just remove them. The official one does define the ANDROID variable, but only in an "android-legacy.toolchain.cmake". I think the standard way to do this is CMAKE_SYSTEM_NAME so switch to that. Change-Id: I3f3fa69d482893c333ae06f54ac39434c3c6a56c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65670 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-12-04Fix build with -Wmissing-field-initializersDavid Benjamin1-2/+1
Since it's otherwise pretty tedious, let's try this with C99 designated initializers. From testing, I remember they worked pretty reliably in C. (In C++, it's a little trickier because MSVC won't accept them outside C++20. Although I think all our supported MSVCs have a C++20 mode now...) Fixed: 671 Change-Id: Ia29ade8721ecfe2140a2d183ad60c8a730c631f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64447 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-11-21Remove the _BORINGSSL_LIBPKI_ definesDavid Benjamin1-2/+0
Now that this is the source of truth, this isn't really doing anything. Update-Note: _BORINGSSL_LIBPKI_ in build files can be removed. Bug: 658 Change-Id: I6daacf692bf4bf51d9822d1b91237625b83d7849 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64027 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-09-18Bump the minimum CMake version to 3.12David Benjamin1-1/+1
CMake 3.12 was released July 2018, so it meets our five year rule. [0] also requires a CMake version newer than 3.12. [0] https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md Change-Id: I2b21d68e3a379108edde9c7d13450bba52f41235 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63105 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-09-05Update googletest and include googlemockDavid Benjamin1-3/+11
Some tests in the Chromium verifier use gmock. Since upstream googletest considers them a single project now, just import both of them. Update-Note: As part of this, I've made gtest_main.cc now initializes gmock alongside gtest. This means BoringSSL's test targets now depend on both. Downstream builds where googletest and googlemock are separate build targets may need to add a dependency. (Though every downstream test I looked at treats them as one target, so this is most likely a no-op.) Bug: chromium:1322914 Change-Id: Ief38c675bc13a4639dee061d058580967ab99d41 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62945 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-08-30Initialize libunwind cursors from the signal handler's ucontext_tDavid Benjamin1-1/+1
unw_context_t is, at least on x86_64, the same type as ucontext_t. Passing that into unw_init_local doesn't work, but there's a unw_init_local2 in libunwind 1.3.0 or later, which has a flag for this case. This avoids needing to unwind past the signal handler stack frames, which is both simpler and faster. (Shaved around 10 seconds off running all the unwind tests on my machine.) Change-Id: I09c130e76682d63e51b7b9de9ff5b91415e26f32 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62867 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-07-05Use sources.cmake for the bssl toolDavid Benjamin1-1/+5
Bug: 542 Change-Id: I94684f2398a28792cc0a31c8e776eecac8cc3cba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61305 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-07-05Use sources.cmake for the test_support libraryDavid Benjamin1-4/+15
As part of this, align the generated and standalone builds in how crypto/test/gtest_main.cc is added. Since not all test targets (urandom_test) include gtest_main.cc, and the generated one just manually adds it to the file lists, just put it into the file lists ahead of time. That way we don't need to synchronize the dependency information with the generated build. This also aligns the generated build with https://boringssl-review.googlesource.com/c/boringssl/+/56567 to put files like crypto/test/abi_test.cc and crypto/test/file_test_gtest.cc in the test_support library. Update-Note: If something odd happens with the test_support library in downstream builds, this CL is probably to blame. Bug: 542 Change-Id: I235e0ccd0432f4b380a92b265ede35eb8a6a6e36 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61288 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-07-05Use sources.cmake for test binariesDavid Benjamin1-0/+27
CMake and the generate builds now broadly share a source of truth for the test files. Update-Note: In the standalone CMake build, build/crypto/crypto_test is now build/crypto_test, etc. For now, the build still copies the outputs to the subdirectories (it's cheap and avoids some workflow turbulence), but I'm thinking we keep that for six months or so and then remove it. Bug: 542 Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-07-03Use sources.cmake for pki and pki_testDavid Benjamin1-1/+21
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>
2023-06-30Use file(STRINGS) to read go_tests.txtDavid Benjamin1-4/+1
Inspired by https://boringssl-review.googlesource.com/c/boringssl/+/61245, though it looks like we do still need CMAKE_CONFIGURE_DEPENDS to tell CMake to rerun itself. Change-Id: Iec2d23590dd45c647c5c53dc80aa8420795a7e73 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61265 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-06-22Bring in the core of chromium certificate verifier as libpkiBob Beck1-1/+3
Initially this leaves the canonical source in chrome, Additions and fillins are committed directly, the chrome files are coverted using the IMPORT script run from the pki directory for the moment. The intention here is to continue frequent automatic conversion (and avoid wholesale cosmetic changes in here for now) until chrome converts to use these files in place of it's versions. At that point these will become the definiative files, and the IMPORT script can be tossed out. A middle step along the way will be to change google3's verify.cc in third_party/chromium_certificate_verifier to use this instead of it's own extracted copy. Status (and what is not done yet) being roughly tracked in README.md Bug: chromium:1322914 Change-Id: Ibdb5479bc68985fa61ce6b10f98f31f6b3a7cbdf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60285 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-05-08Bump the minimum supported MSVC version to VS2019David Benjamin1-5/+0
This aligns with https://github.com/google/oss-policies-info/pull/8 and https://github.com/grpc/grpc/pull/32614. VS2019 adds a C11 mode, which is useful for us, because it means stdalign.h works correctly. Also bump the minimum Windows SDK to https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/. If you have a new MSVC, CMake will enable C11 mode by default. But if C11 mode is enabled but your Windows SDK is too old, things break. After this change, the CI will include some redundant configurations. All the VS2017 configurations will start testing on VS2019, so the VS2019-specific configurations won't do anything. I'll follow this up with a change to bump those to VS2022, where we're currently missing coverage. Update-Note: BoringSSL now requires VS2019 or later and no longer supports VS2017. VS2017 has been past its "mainstream end date" for over a year now, per https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2017 Change-Id: I3f359e8ea7c9428ddaa9fcc4ffead2ef903398be Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59665 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-04-21Only rerun bindgen when its dependencies changeDavid Benjamin1-0/+1
This took a bit of wrangling to get the depfiles working, but I eventually figured it out. ninja -d explain is very useful. Fixed: 597 Change-Id: I909a4c9418e9dc954e3d328da8f3a825e62544e4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59005 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2023-02-27Fix ninja run_testsDavid Benjamin1-1/+1
https://boringssl-review.googlesource.com/c/boringssl/+/57645 wasn't quite right. The cd to run ssl/test/runner affects the subsequent commands. Fix this by running the Go tests first. They're very fast compared to the others anyway. Change-Id: Id5ea54a9787173eb3ed80e9db2c9ecfe064a93b0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57688 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-27Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIRDavid Benjamin1-8/+8
If another project includes us as a subproject, as gRPC does, CMAKE_SOURCE_DIR points to the top-level source directory, not ours. PROJECT_SOURCE_DIR points to ours. Likewise, CMAKE_BINARY_DIR will point to the top-level one. gRPC doesn't consume this CMake build, but in preparation for eventually unifying the two CMake builds, replace CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR with a combination of CMAKE_CURRENT_{SOURCE,BINARY}_DIR and PROJECT_SOURCE_DIR. There's one more CMAKE_SOURCE_DIR which controls some default install directory. I've left that one alone for now as I'm not sure what to do with it. Probably the answer is to, like in gRPC, disable the install target by default when we're not the top-level source directory. Bug: 542 Change-Id: Iea26bbef8a4637671fd0e7476101512e871e7e18 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57686 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-27Run Go tests as part of run_testsDavid Benjamin1-0/+8
This doesn't run them as part of CI yet, but I'll follow-up with a recipe change to read the same util/go_tests.txt file and run Go tests in there. Bug: 506 Change-Id: Ifd527b1d00ec30896582360132249230fab7e7c0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57645 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-02-15Make boringssl_gtest_main a STATIC libraryDavid Benjamin1-0/+3
Prior to 3.12 (which we won't be requiring until July), OBJECT libraries cannot be used with target_link_libraries. That means they cannot pick up INTERFACE_INCLUDE_DIRECTORIES, which makes them pretty unusable in the "modern CMake" style. Just switch it to a static library to unbreak the build in CMake 3.10. For some link ordering reason I don't understand, this also requires explicitly linking boringssl_gtest to libcxx when we USE_CUSTOM_LIBCXX is set. Change-Id: Ia9d8351551f5da060248aa3ca73fe04473bf62aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57345 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-02-14Remove global_target from build.David Benjamin1-7/+3
This was added with the generated symbol-prefixing header. But it seems to be sufficient for crypto to have a dependency on the generated header, along with some of the stray bits of delocate. It's a little unclear from CMake documentation how these are processed; normally .o files can be built before libraries are built or linked, only the link step depends on. But, empirically, if A links B, and B has a dependency on C, then CMake seems to run C before building any of A. I tested this by making a small project where the generation step slept for three seconds and running with enough parallelism that we'd have tripped. Interestingly, in the Makefile output, the individual object file targets didn't have that dependency, but the target itself did. But this was true on both A and B, so I think that just might not work. Also fix the dependency in the custom target. The old formulation broke when using an absolute path to the symbols file. Change-Id: I2053d44949f907d465da403a5ec69c191740268f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-14Don't include custom builds of libc++ in CMake installsDavid Benjamin1-5/+27
Also stick the very verbose default install directory in a variable so we don't have to repeat it everywhere. Change-Id: I1a6a85c4d42d3a6e766e52b2d0ecd8e81c6ed4e3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56607 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-08Move Go CMake support into its own file.David Benjamin1-49/+3
Slowly reduce clutter in the top-level CMake file. Change-Id: Ib7ca2aee7337db82ed1989c56bbaaf6ee5da0768 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56569 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-06Remove old clang-cl workaroundDavid Benjamin1-3/+0
Looks like this has since been fixed (or isn't hitting GTest anymore for some reason). Bug: chromium:772117 Change-Id: I2c2fb694e4429281e20fd252ef9c2c34e29a425c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56570 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-06Limit the CMake -isysroot assembly workaround to older CMakeDavid Benjamin1-2/+3
It was fixed in CMake 3.19 with https://gitlab.kitware.com/cmake/cmake/-/issues/20771 Change-Id: Ia76ab6690e233bc650e11a79db381c00f21c83a1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56568 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-06Clean up test_support_lib and GTest dependencies slightly.David Benjamin1-3/+5
test_support_lib depends on GTest and should be marked as such. Historically it was a bit fuzzy, but now it's unambiguous. With that cleaned up, we can remove one of the global include_directories calls and rely on CMake's INTERFACE_INCLUDE_DIRECTORIES machinery. (CMake's documentation and "modern CMake" prefers setting include directories on the target and letting them flow up the dependency tree, rather than configuring it globally across the project.) Change-Id: I364df834d62328b69f146fbe35c10af97618a713 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56567 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-06Move malloc failure testing into OPENSSL_mallocDavid Benjamin1-0/+4
Rather than trying to override the actual malloc symbol, just intercept OPENSSL_malloc and gate it on a build flag. (When we first wrote these, OPENSSL_malloc was just an alias for malloc.) This has several benefits: - This is cross platform. We don't interfere with sanitizers or the libc, or have to mess with global symbols. - This removes the reason bssl_shim and handshaker linked test_support_lib, so we can fix the tes_support_lib / gtest dependency. - If we ever reduce the scope of fallible mallocs, we'll want to constrain the tests to only the ones that are fallible. An interception strategy like this can do it. Hopefully that will also take less time to run in the future. Also fix the ssl malloc failure tests, as they haven't been working for a while. (Malloc failure tests still take far too long to run to the end though. My immediate motivation is less malloc failure and more to tidy up the build.) Bug: 563 Change-Id: I32165b8ecbebfdcfde26964e06a404762edd28e3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56925 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-02-01Move OpenSSLConfig.cmake into the cmake/ directoryDavid Benjamin1-1/+1
We've already put perlasm.cmake in there. I figure CMake helper files can go in there. It also seems to match what other projects too. Change-Id: Ief6b10cf4e80b8d4b52ca53b90aa425b32037e52 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56566 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-01-26Set C11 in all compilers.David Benjamin1-4/+2
I'm not sure why I conditioned C11 on non-Clang MSVC. I think I meant to invert that condition to NOT MSVC OR CLANG. But given that it worked, just do it across the board. (Though we support VS2017, which doesn't support a C11 mode, so this is slightly curious. It may just be that pre-VS2019, this option is a no-op.) Change-Id: I271ffd2a913c1aa676fea7ec41f30c1896bb5955 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56325 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-01-26Reduce architecture detection in CMake.David Benjamin1-53/+30
This follows up on https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make the CMake build rely on the C preprocessor, rather than CMake. While not as disasterous as pre-@platforms Bazel, CMake's build-level platform selection is not ideal: - CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names for the same architecture, and sometimes, e.g., building for 32-bit Windows will still report "AMD64". - On Apple platforms, there is a separate and technically multi-valued CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but don't support the multi-value case. Instead, broadly detect whether we expect gas or nasm, and then pull in every matching file, relying on the C preprocessor to exclude files as needed. This also fixes a quirk in generate_build_files.py, where it needed to use the filename to detect the architecture of a perlasm script in CMake. This CL only applies to the standalone CMake build. The generated file lists do not change. I'm not sure yet whether this strategy will be appropriate for all those builds, so this starts with just the CMake one. This hits a pair of nuisances with the Apple linker. First, Apple has two ways to invoke the linker. The new way is libtool, the old way is ranlib. Warnings are different between the two. In both libtool and ranlib, for x86_64 but not aarch64, we get a warning about files with no symbols. This warning fires for us, but this change makes it much, much noisier. Oddly, this warning does not trigger when building for aarch64, just x86_64. I'm not sure whether this is because aarch64 hits new behavior or it happens that aarch64 object files always contain some dummy symbol. libtool has a -no_warning_for_no_symbols flag to silence this warning. Unfortunately, CMake uses ranlib and there is no way, from what I can tell, to pass this flag to ranlib. See https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698 Since this seems to be a broader CMake limitation, and we were already living with some of these warnings, I've left this alone. But this CL does make macOS x86_64 CMake builds very noisy. I haven't used it here, but LLVM has a pile of CMake goo that switches CMake to using libtool and passes in that flag. Trialing it out reveals *different* issue, which I have worked around: When invoked as libtool, but not as ranlib, the Apple linker also warns when two object files have the same name. This appears to be a holdover from static libraries using ar, even though ld does not actually invoke ar. There appears to be no way to suppress this warning. Though we don't use libtool, we can probably assume most non-CMake builds will be using the modern spelling. So I've suffixed each perlasm file with the OS. This means, in generate_build_files.py, we no longer need a separate directory for each platform. For now, I've kept that alone, because some update scripts rely on that spelling to delete old files. Update-Note: If the CMake build fails to build somewhere for an assembly-related reasons, it's probably from this CL. Bug: 542 Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-01-13Simplify MSVC warning configurationDavid Benjamin1-53/+4
We've been setting /Wall on MSVC for a while, but /Wall in MSVC is really "all". I.e., it's -Weverything in Clang and GCC, and includes many warnings that are simply diagnostics. MSVC's own headers do not promise to be clean under /Wall. Rather, the equivalent of Clang and GCC's -Wall is /W4, which MSVC does promise to pass. Under /Wall, every new MSVC release we've had to update an ever-growing list of warning exceptions, to disable the off-by-default warnings that were off for a reason. Switch to MSVC's recommendations and just enable /W4. From there, I've trimmed the exception list, now that we don't need to re-disable disabled warnings. A few non-disabled warnings also no longer need exceptions. This should fix the build with VS2022, which was failing due to C5264. C5264 flags a couple of instances in the library, but tons and tons in MSVC headers and googletest. (The instances in the library are a little goofy and reflect things that should have been 'inline constexpr', but we can't rely on C++17 yet. Though I may go add a compat macro for that.) Fixed: 552 Change-Id: I9031c0d5bd4c7a4df1dc3040b38af9cfbcffc06e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56045 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2022-12-08Drop the workaround for the third-party Android CMake toolchain.David Benjamin1-7/+0
When we first added Android support to the CMake build, we used a third-party toolchain file, https://github.com/taka-no-me/android-cmake. That project hasn't been updated since 2015 and, among other things, doesn't support Armv8. In 2017, we replaced it with the NDK's build-in toolchain file, which no longer needed a particular workaround for ASM flags. See https://boringssl-review.googlesource.com/c/boringssl/+/24165 and https://boringssl-review.googlesource.com/c/boringssl/+/24164 Drop this workaround now. Change-Id: I4af78d641b0c9b9608aaaa5ca31b9e80de024ab2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55627 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-11-22Update build tools.David Benjamin1-3/+9
The clang script needed to be tweaked slightly because they've since changed the URL. Also libc++ now needs to be built as C++20. (The bundled libc++ is only built in some of our test configs, so this doesn't imply a C++20 dependency across the board.) Change-Id: I0a9e3aed71268bcd37059af8549a23cfc0270b05 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55272 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2022-11-22Bump minimum CMake version.David Benjamin1-1/+1
CMake 3.10 was released November 20, 2017, which is now more than five years ago. Change-Id: Ic939fd137983914ce1041740f58d98a56433e739 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55271 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2022-10-27Remove tautological comparison.David Benjamin1-1/+1
Also build with -Wtype-limits to catch future instances. Bug: 529 Change-Id: I2d84dc1824ffc7cd92411f49c9f953bcd3c74331 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55045 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2022-10-14Enable -Wstring-concatenation and silence warning.David Benjamin1-0/+10
Newer versions of Clang have a warning to detect "suspicious" uses of string concatenation, where they think a comma or so was missing. It flags a false positive in x509_test.cc, which we can silence with parentheses. Fuchsia builds with this warning enabled, so enable it to catch future instances. I couldn't find official documentation on when this was added, but empirically it's in my clang-12 but not my clang-11. That's recent enough that adding a version check seems prudent. Unfortunately, version-detecting Clang is complex because AppleClang uses completely different versions. There's a handy table on Wikipedia that maps them. Change-Id: I503c21d39bb5c68dda9bda6da693c7208f3af561 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54785 Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-07-12Bump CMake requirement to 3.8.David Benjamin1-6/+9
CMake 3.8 was released April 10, 2017, which puts it past our five year horizon. (CMake 3.9 is just a few days short of it, so using 3.8 for now.) In particular, depending on 3.7+ gets us some nice features like VERSION_GREATER_EQUAL. Change-Id: I90457ad41e7add3c6b2dd3664da964c4b6ede499 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53345 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-06-08Add support for RISC-V 64-bit architectureRebecca Chang Swee Fun1-0/+2
Signed-off-by: Rebecca Chang Swee Fun <rebecca.chang@starfivetech.com> Change-Id: If6424a3b268943a5e2dc847f94b509d4b509df79 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52765 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
generated by cgit v1.1 at 2024-07-09 23:33:18 +0000