Chiebot-Mirror
/
boringssl
mirror of https://gitee.com/mirrors/boringssl.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
Mirror of BoringSSL (grpc依赖) https://boringssl.googlesource.com/boringssl
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1493 Commits
59 Branches
16 Tags
480 MiB
Tag: Branch: Tree: 197b57154f
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '197b57154f'
${ noResults }
boringssl/CMakeLists.txt

644 lines
23 KiB
Raw Normal View History Unescape

Bump minimum CMake version. 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>
2 years ago
cmake_minimum_required(VERSION 3.10)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
# Defer enabling C and CXX languages.
project(BoringSSL NONE)
Add CMake install rules. This creates an install directory under the top level source directory. The install contains a CMake config file that produces variables and targets compatible with FindOpenSSL, or the directory can be scanned by FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with third-party dependencies that find an SSL implementation via CMake. Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
# Don't install BoringSSL to system directories by default; it has no stable
# ABI. Instead, default to an "install" directory under the source.
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX ${CMAKE_SOURCE_DIR}/install CACHE PATH "" FORCE)
endif()
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(WIN32)
# On Windows, prefer cl over gcc if both are available. By default most of
# the CMake generators prefer gcc, even on Windows.
set(CMAKE_GENERATOR_CC cl)
endif()
include(sources.cmake)
Move Go CMake support into its own file. 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>
2 years ago
include(cmake/go.cmake)
Only rerun bindgen when its dependencies change 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>
2 years ago
include(cmake/paths.cmake)
Reduce architecture detection in CMake. 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>
2 years ago
include(cmake/perlasm.cmake)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
enable_language(C)
enable_language(CXX)
Fix build for older CMake versions. CMake versions newer than ~3.1x automatically determine the subdirectory under CMAKE_INSTALL_PREFIX using the type of the installed target. Older versions need this to be manually computed using the GNUInstallDirs library. Since we override the CMAKE_INSTALL_PREFIX default, this just controls the internal layout of the install/ directory generated underneath the boringssl checkout. Bug: 488 Change-Id: I97b02006301e463bb0cfd54acb2b27656484cc85 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52345 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
include(GNUInstallDirs)
Don't include custom builds of libc++ in CMake installs 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>
2 years ago
# CMake versions before 3.14 do not have default destination values. Executable
# and library targets that use a default destination should include this
# variable.
if(CMAKE_VERSION VERSION_LESS "3.14")
set(INSTALL_DESTINATION_DEFAULT
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
endif()
# Wrap the CMake install function so we can disable it.
set(INSTALL_ENABLED 1)
function(install_if_enabled)
if(INSTALL_ENABLED)
install(${ARGV})
endif()
endfunction()
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(ANDROID)
Move Go CMake support into its own file. 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>
2 years ago
# Android-NDK CMake files reconfigure the path and so Perl won't be found.
# However, ninja will still find them in $PATH if we just name them.
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(NOT PERL_EXECUTABLE)
set(PERL_EXECUTABLE "perl")
endif()
else()
find_package(Perl REQUIRED)
endif()
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND NOT CMAKE_CROSSCOMPILING)
find_package(PkgConfig QUIET)
if (PkgConfig_FOUND)
pkg_check_modules(LIBUNWIND libunwind-generic)
if(LIBUNWIND_FOUND)
add_definitions(-DBORINGSSL_HAVE_LIBUNWIND)
else()
message("libunwind not found. Disabling unwind tests.")
endif()
else()
message("pkgconfig not found. Disabling unwind tests.")
endif()
endif()
if(USE_CUSTOM_LIBCXX)
set(BORINGSSL_ALLOW_CXX_RUNTIME 1)
endif()
if(BORINGSSL_ALLOW_CXX_RUNTIME)
add_definitions(-DBORINGSSL_ALLOW_CXX_RUNTIME)
endif()
string(TOLOWER "${CMAKE_BUILD_TYPE}" CMAKE_BUILD_TYPE_LOWER)
if(NOT FIPS)
if(CMAKE_BUILD_TYPE_LOWER STREQUAL "relwithassert" OR
NOT CMAKE_BUILD_TYPE_LOWER MATCHES "rel")
add_definitions(-DBORINGSSL_DISPATCH_TEST)
# CMake automatically connects include_directories to the NASM
# command-line, but not add_definitions.
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -DBORINGSSL_DISPATCH_TEST")
endif()
endif()
# Add a RelWithAsserts build configuration. It is the same as Release, except it
# does not define NDEBUG, so asserts run.
foreach(VAR CMAKE_C_FLAGS CMAKE_CXX_FLAGS CMAKE_ASM_FLAGS)
string(REGEX REPLACE "(^| )[/-]DNDEBUG( |$)" " " "${VAR}_RELWITHASSERTS"
"${${VAR}_RELEASE}")
endforeach()
if(BORINGSSL_PREFIX AND BORINGSSL_PREFIX_SYMBOLS)
add_definitions(-DBORINGSSL_PREFIX=${BORINGSSL_PREFIX})
# CMake automatically connects include_directories to the NASM command-line,
# but not add_definitions.
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -DBORINGSSL_PREFIX=${BORINGSSL_PREFIX}")
# Use "symbol_prefix_include" to store generated header files
include_directories(${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include)
add_custom_command(
OUTPUT symbol_prefix_include/boringssl_prefix_symbols.h
symbol_prefix_include/boringssl_prefix_symbols_asm.h
symbol_prefix_include/boringssl_prefix_symbols_nasm.inc
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include
COMMAND ${GO_EXECUTABLE} run ${CMAKE_CURRENT_SOURCE_DIR}/util/make_prefix_headers.go -out ${CMAKE_CURRENT_BINARY_DIR}/symbol_prefix_include ${BORINGSSL_PREFIX_SYMBOLS}
DEPENDS util/make_prefix_headers.go
Remove global_target from build. 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>
2 years ago
${BORINGSSL_PREFIX_SYMBOLS})
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
# add_dependencies needs a target, not a file, so we add an intermediate
# target.
add_custom_target(
boringssl_prefix_symbols
DEPENDS symbol_prefix_include/boringssl_prefix_symbols.h
symbol_prefix_include/boringssl_prefix_symbols_asm.h
symbol_prefix_include/boringssl_prefix_symbols_nasm.inc)
elseif(BORINGSSL_PREFIX OR BORINGSSL_PREFIX_SYMBOLS)
message(FATAL_ERROR "Must specify both or neither of BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS")
Remove global_target from build. 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>
2 years ago
else()
add_custom_target(boringssl_prefix_symbols)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
endif()
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(CLANG 1)
endif()
if(CMAKE_SYSTEM_NAME STREQUAL "Emscripten")
set(EMSCRIPTEN 1)
endif()
Use CMake's C/C++ version features. This seems to be the preferred mechanism starting CMake 3.1, and reduces some compiler-specific bits. We can probably also retire -stdlib=libc++ on AppleClang now. https://boringssl-review.googlesource.com/21984 suggests it was needed to make C++11 work, but presumably that's the default stdlib now that the default C++ version is C++11. (If it is needed, that ought to be CMAKE_CXX_STANDARD's responsibility. I don't see any evidence of them setting it, so I'm guessing this is just no longer needed.) Change-Id: Ide1fdbd3d4b8fe37a10a7948171a2c20c9de21f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52647 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
Set C11 in all compilers. 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>
2 years ago
set(CMAKE_C_STANDARD 11)
set(CMAKE_C_STANDARD_REQUIRED ON)
Use CMake's C/C++ version features. This seems to be the preferred mechanism starting CMake 3.1, and reduces some compiler-specific bits. We can probably also retire -stdlib=libc++ on AppleClang now. https://boringssl-review.googlesource.com/21984 suggests it was needed to make C++11 work, but presumably that's the default stdlib now that the default C++ version is C++11. (If it is needed, that ought to be CMAKE_CXX_STANDARD's responsibility. I don't see any evidence of them setting it, so I'm guessing this is just no longer needed.) Change-Id: Ide1fdbd3d4b8fe37a10a7948171a2c20c9de21f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52647 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(CMAKE_COMPILER_IS_GNUCXX OR CLANG)
# Note clang-cl is odd and sets both CLANG and MSVC. We base our configuration
# primarily on our normal Clang one.
Bring in the core of chromium certificate verifier as libpki 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>
2 years ago
# TODO(bbe) took out -Wmissing-field-initializers for pki - fix and put back or disable only for pki
set(C_CXX_FLAGS "-Werror -Wformat=2 -Wsign-compare -Wwrite-strings -Wvla -Wshadow -Wtype-limits")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(MSVC)
# clang-cl sets different default warnings than clang. It also treats -Wall
# as -Weverything, to match MSVC. Instead -W3 is the alias for -Wall.
# See http://llvm.org/viewvc/llvm-project?view=revision&revision=319116
set(C_CXX_FLAGS "${C_CXX_FLAGS} -W3 -Wno-unused-parameter -fmsc-version=1900")
else()
if(EMSCRIPTEN)
# emscripten's emcc/clang does not accept the "-ggdb" flag.
set(C_CXX_FLAGS "${C_CXX_FLAGS} -g")
else()
set(C_CXX_FLAGS "${C_CXX_FLAGS} -ggdb")
endif()
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wall -fvisibility=hidden -fno-common")
endif()
if(CLANG)
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wnewline-eof -fcolor-diagnostics")
else()
# GCC (at least 4.8.4) has a bug where it'll find unreachable free() calls
# and declare that the code is trying to free a stack pointer.
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wno-free-nonheap-object")
endif()
Enable -Wstring-concatenation and silence warning. 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>
2 years ago
# -Wstring-concatenation was added in Clang 12.0.0, which corresponds to
# AppleClang 13.0.0 per the table in
# https://en.wikipedia.org/wiki/Xcode#Toolchain_versions
if((CMAKE_C_COMPILER_ID STREQUAL "Clang" AND
CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL "12.0.0") OR
(CMAKE_C_COMPILER_ID STREQUAL "AppleClang" AND
CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL "13.0.0"))
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wstring-concatenation")
endif()
Bump CMake requirement to 3.8. 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>
2 years ago
if(CLANG OR CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL "7.0.0")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wimplicit-fallthrough")
endif()
Use uint16_t in TestConfig and enable -Wformat-signedness. This silences a pile of -Wformat-signedness warnings. We still need casts in a few places where the API gives int but really wanted uint16_t. There I cast to unsigned instead of uint16_t for the sake of not losing information. With that, we should be -Wformat-signedness-clean on GCC, so enable the warning. Bug: 450 Change-Id: I3ab10348bb47d398b8b9b39acf360284a8ab04d7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50771 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
if(CMAKE_COMPILER_IS_GNUCXX)
set(C_CXX_FLAGS "${C_CXX_FLAGS} -Wformat-signedness")
endif()
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${C_CXX_FLAGS} -Wmissing-prototypes -Wold-style-definition -Wstrict-prototypes")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${C_CXX_FLAGS} -Wmissing-declarations")
Use CMake's C/C++ version features. This seems to be the preferred mechanism starting CMake 3.1, and reduces some compiler-specific bits. We can probably also retire -stdlib=libc++ on AppleClang now. https://boringssl-review.googlesource.com/21984 suggests it was needed to make C++11 work, but presumably that's the default stdlib now that the default C++ version is C++11. (If it is needed, that ought to be CMAKE_CXX_STANDARD's responsibility. I don't see any evidence of them setting it, so I'm guessing this is just no longer needed.) Change-Id: Ide1fdbd3d4b8fe37a10a7948171a2c20c9de21f9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52647 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
3 years ago
if(NOT MSVC AND NOT BORINGSSL_ALLOW_CXX_RUNTIME)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions -fno-rtti")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
endif()
# In GCC, -Wmissing-declarations is the C++ spelling of -Wmissing-prototypes
# and using the wrong one is an error. In Clang, -Wmissing-prototypes is the
# spelling for both and -Wmissing-declarations is some other warning.
#
# https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options
# https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-prototypes
# https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-declarations
if(CLANG)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wmissing-prototypes")
endif()
elseif(MSVC)
set(MSVC_DISABLED_WARNINGS_LIST
"C4100" # 'exarg' : unreferenced formal parameter
"C4127" # conditional expression is constant
"C4244" # 'function' : conversion from 'int' to 'uint8_t',
# possible loss of data
"C4267" # conversion from 'size_t' to 'int', possible loss of data
"C4706" # assignment within conditional expression
)
string(REPLACE "C" " -wd" MSVC_DISABLED_WARNINGS_STR
${MSVC_DISABLED_WARNINGS_LIST})
Simplify MSVC warning configuration 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>
2 years ago
set(CMAKE_C_FLAGS "-utf-8 -W4 -WX ${MSVC_DISABLED_WARNINGS_STR}")
set(CMAKE_CXX_FLAGS "-utf-8 -W4 -WX ${MSVC_DISABLED_WARNINGS_STR}")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
endif()
if(WIN32)
add_definitions(-D_HAS_EXCEPTIONS=0)
add_definitions(-DWIN32_LEAN_AND_MEAN)
add_definitions(-DNOMINMAX)
# Allow use of fopen.
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
endif()
Limit _XOPEN_SOURCE to Linux. POSIX feature macros are a mess. Reportedly, FreeBSD also breaks with _XOPEN_SOURCE, so try leaving it unset by default. Update-Note: It's possible this will break yet another obscure UNIX. Hopefully we can eventually find a combination that works? Bug: 471 Change-Id: I103f8093110d343789b9c5a22eb056ab78d9cd14 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51145 Reviewed-by: Adam Langley <agl@google.com>
3 years ago
# pthread_rwlock_t on Linux requires a feature flag. We limit this to Linux
# because, on Apple platforms, it instead disables APIs we use. See compat(5)
# and sys/cdefs.h. Reportedly, FreeBSD also breaks when this is set. See
# https://crbug.com/boringssl/471.
if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_XOPEN_SOURCE=700")
endif()
if(FUZZ)
if(NOT CLANG)
message(FATAL_ERROR "You need to build with Clang for fuzzing to work")
endif()
if(CMAKE_C_COMPILER_VERSION VERSION_LESS "6.0.0")
message(FATAL_ERROR "You need Clang ≥ 6.0.0")
endif()
add_definitions(-DBORINGSSL_UNSAFE_DETERMINISTIC_MODE)
set(RUNNER_ARGS "-deterministic")
if(NOT NO_FUZZER_MODE)
add_definitions(-DBORINGSSL_UNSAFE_FUZZER_MODE)
set(RUNNER_ARGS ${RUNNER_ARGS} "-fuzzer" "-shim-config" "fuzzer_mode.json")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address,fuzzer-no-link -fsanitize-coverage=edge,indirect-calls")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address,fuzzer-no-link -fsanitize-coverage=edge,indirect-calls")
endif()
add_definitions(-DBORINGSSL_IMPLEMENTATION)
if(BUILD_SHARED_LIBS)
add_definitions(-DBORINGSSL_SHARED_LIBRARY)
# Enable position-independent code globally. This is needed because
# some library targets are OBJECT libraries.
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
endif()
if(MSAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable MSAN unless using Clang")
endif()
if(ASAN)
message(FATAL_ERROR "ASAN and MSAN are mutually exclusive")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer")
endif()
if(ASAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable ASAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer")
endif()
if(CFI)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable CFI unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=cfi -fno-sanitize-trap=cfi -flto=thin")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=cfi -fno-sanitize-trap=cfi -flto=thin")
# We use Chromium's copy of clang, which requires -fuse-ld=lld if building
# with -flto. That, in turn, can't handle -ggdb.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=lld")
string(REPLACE "-ggdb" "-g" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
string(REPLACE "-ggdb" "-g" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
# -flto causes object files to contain LLVM bitcode. Mixing those with
# assembly output in the same static library breaks the linker.
set(OPENSSL_NO_ASM "1")
endif()
if(TSAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable TSAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=thread")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=thread")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=thread")
endif()
if(UBSAN)
if(NOT CLANG)
message(FATAL_ERROR "Cannot enable UBSAN unless using Clang")
endif()
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=undefined")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=undefined")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=undefined")
if(NOT UBSAN_RECOVER)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-sanitize-recover=undefined")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-sanitize-recover=undefined")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fno-sanitize-recover=undefined")
endif()
endif()
if(GCOV)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage")
endif()
if(FIPS)
add_definitions(-DBORINGSSL_FIPS)
if(FIPS_BREAK_TEST)
add_definitions("-DBORINGSSL_FIPS_BREAK_${FIPS_BREAK_TEST}=1")
endif()
# The FIPS integrity check does not work for ASan and MSan builds.
if(NOT ASAN AND NOT MSAN)
if(BUILD_SHARED_LIBS)
set(FIPS_SHARED "1")
else()
set(FIPS_DELOCATE "1")
endif()
endif()
if(FIPS_SHARED)
# The Android CMake files set -ffunction-sections and -fdata-sections,
# which is incompatible with FIPS_SHARED.
set(CMAKE_C_FLAGS
"${CMAKE_C_FLAGS} -fno-function-sections -fno-data-sections")
set(CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS} -fno-function-sections -fno-data-sections")
endif()
endif()
if(OPENSSL_SMALL)
add_definitions(-DOPENSSL_SMALL)
endif()
if(CONSTANT_TIME_VALIDATION)
add_definitions(-DBORINGSSL_CONSTANT_TIME_VALIDATION)
# Asserts will often test secret data.
add_definitions(-DNDEBUG)
endif()
Move malloc failure testing into OPENSSL_malloc 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>
2 years ago
if(MALLOC_FAILURE_TESTING)
add_definitions(-DBORINGSSL_MALLOC_FAILURE_TESTING)
endif()
Reduce architecture detection in CMake. 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>
2 years ago
if(OPENSSL_NO_ASM)
add_definitions(-DOPENSSL_NO_ASM)
endif()
if(FIPS_DELOCATE OR NOT OPENSSL_NO_ASM)
# On x86 and x86_64 Windows, we use the NASM output.
if(WIN32 AND CMAKE_SYSTEM_PROCESSOR MATCHES "AMD64|x86_64|amd64|x86|i[3-6]86")
enable_language(ASM_NASM)
set(OPENSSL_NASM TRUE)
set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -gcv8")
else()
enable_language(ASM)
set(OPENSSL_ASM TRUE)
Limit the CMake -isysroot assembly workaround to older CMake 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>
2 years ago
# Work around https://gitlab.kitware.com/cmake/cmake/-/issues/20771 in older
# CMake versions.
if(APPLE AND CMAKE_VERSION VERSION_LESS 3.19)
Reduce architecture detection in CMake. 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>
2 years ago
if(CMAKE_OSX_SYSROOT)
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -isysroot \"${CMAKE_OSX_SYSROOT}\"")
endif()
foreach(arch ${CMAKE_OSX_ARCHITECTURES})
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -arch ${arch}")
endforeach()
endif()
if(NOT WIN32)
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -Wa,--noexecstack")
endif()
# Clang's integerated assembler does not support debug symbols.
if(NOT CMAKE_ASM_COMPILER_ID MATCHES "Clang")
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -Wa,-g")
endif()
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
endif()
endif()
if(OPENSSL_NO_SSE2_FOR_TESTING)
add_definitions(-DOPENSSL_NO_SSE2_FOR_TESTING)
endif()
if(USE_CUSTOM_LIBCXX)
if(NOT CLANG)
message(FATAL_ERROR "USE_CUSTOM_LIBCXX only supported with Clang")
endif()
Don't include custom builds of libc++ in CMake installs 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>
2 years ago
# CMake does not allow installing a library without installing dependencies.
# If we installed libcrypto, we'd have to install our custom libc++, which
# does not make sense. As this is a test-only configuration, disable
# installing.
set(INSTALL_ENABLED 0)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
# CMAKE_CXX_FLAGS ends up in the linker flags as well, so use
# add_compile_options. There does not appear to be a way to set
# language-specific compile-only flags.
add_compile_options("-nostdinc++")
set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS} -nostdlib++")
include_directories(
SYSTEM
Update tools. We haven't done this in a while. This also tests more codepaths in in the previous Python 3 update. libc++ required a few more build tweaks. Also the CMake update was necessary to update the NDK. Older CMake cannot detect CMAKE_LINKER in the newer NDK. Change-Id: I59ab1c6b074b805dd4b8a6ab596c4cf469d5bfa9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50167 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
3 years ago
util/bot/libcxx-config
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
util/bot/libcxx/include
util/bot/libcxxabi/include
)
# This is patterned after buildtools/third_party/libc++/BUILD.gn and
# buildtools/third_party/libc++abi/BUILD.gn in Chromium.
file(GLOB LIBCXX_SOURCES "util/bot/libcxx/src/*.cpp")
file(GLOB LIBCXXABI_SOURCES "util/bot/libcxxabi/src/*.cpp")
# This file is meant for exception-less builds.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/cxa_noexception.cpp")
# libc++ also defines new and delete.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/stdlib_new_delete.cpp")
if(TSAN)
# ThreadSanitizer tries to intercept these symbols. Skip them to avoid
# symbol conflicts.
list(REMOVE_ITEM LIBCXXABI_SOURCES "trunk/src/cxa_guard.cpp")
endif()
add_library(libcxxabi ${LIBCXXABI_SOURCES})
target_compile_definitions(
libcxxabi PRIVATE
-D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS
)
add_library(libcxx ${LIBCXX_SOURCES})
if(ASAN OR MSAN OR TSAN)
# Sanitizers try to intercept new and delete.
target_compile_definitions(
libcxx PRIVATE
-D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS
)
endif()
target_compile_definitions(
libcxx PRIVATE
-D_LIBCPP_BUILDING_LIBRARY
-DLIBCXX_BUILDING_LIBCXXABI
)
Update build tools. 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>
2 years ago
set_target_properties(
libcxx libcxxabi PROPERTIES
COMPILE_FLAGS "-Wno-missing-prototypes -Wno-implicit-fallthrough"
# libc++ and libc++abi must be built in C++20 mode.
CXX_STANDARD 20
CXX_STANDARD_REQUIRED TRUE
)
# libc++abi depends on libc++ internal headers.
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
set_property(TARGET libcxx libcxxabi APPEND PROPERTY INCLUDE_DIRECTORIES "${CMAKE_CURRENT_SOURCE_DIR}/util/bot/libcxx/src")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
target_link_libraries(libcxx libcxxabi)
endif()
# Add minimal googletest targets. The provided one has many side-effects, and
# googletest has a very straightforward build.
add_library(boringssl_gtest third_party/googletest/src/gtest-all.cc)
Make boringssl_gtest_main a STATIC library 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>
2 years ago
if(USE_CUSTOM_LIBCXX)
target_link_libraries(boringssl_gtest libcxx)
endif()
Clean up test_support_lib and GTest dependencies slightly. 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>
2 years ago
target_include_directories(
boringssl_gtest
PUBLIC third_party/googletest/include
PRIVATE third_party/googletest
)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
# Declare a dummy target to build all unit tests. Test targets should inject
# themselves as dependencies next to the target definition.
add_custom_target(all_tests)
# On Windows, CRYPTO_TEST_DATA is too long to fit in command-line limits.
# TODO(davidben): CMake 3.12 has a list(JOIN) command. Use that when we've
# updated the minimum version.
set(EMBED_TEST_DATA_ARGS "")
foreach(arg ${CRYPTO_TEST_DATA})
set(EMBED_TEST_DATA_ARGS "${EMBED_TEST_DATA_ARGS}${arg}\n")
endforeach()
file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/embed_test_data_args.txt"
"${EMBED_TEST_DATA_ARGS}")
add_custom_command(
OUTPUT crypto_test_data.cc
COMMAND ${GO_EXECUTABLE} run util/embed_test_data.go -file-list
"${CMAKE_CURRENT_BINARY_DIR}/embed_test_data_args.txt" >
"${CMAKE_CURRENT_BINARY_DIR}/crypto_test_data.cc"
DEPENDS util/embed_test_data.go ${CRYPTO_TEST_DATA}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
add_library(crypto_test_data OBJECT crypto_test_data.cc)
add_subdirectory(crypto)
add_subdirectory(ssl)
add_subdirectory(ssl/test)
add_subdirectory(tool)
Drop CAVP code. All FIPS testing is done with ACVP now. We can delete all the CAVP stuff. Change-Id: I459873474e40b0371f9cf760090a130ef9a90a8c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51330 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
add_subdirectory(util/fipstools)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
add_subdirectory(util/fipstools/acvp/modulewrapper)
add_subdirectory(decrepit)
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>
1 year ago
Use sources.cmake for test binaries 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>
1 year ago
# urandom_test is a separate binary because it needs to be able to observe the
# PRNG initialisation, which means that it can't have other tests running before
# it does.
add_executable(urandom_test ${URANDOM_TEST_SOURCES})
target_link_libraries(urandom_test test_support_lib boringssl_gtest crypto)
add_dependencies(all_tests urandom_test)
add_executable(crypto_test ${CRYPTO_TEST_SOURCES} $<TARGET_OBJECTS:crypto_test_data>)
target_link_libraries(crypto_test test_support_lib boringssl_gtest_main crypto)
add_dependencies(all_tests crypto_test)
add_executable(ssl_test ${SSL_TEST_SOURCES})
target_link_libraries(ssl_test test_support_lib boringssl_gtest_main ssl crypto)
add_dependencies(all_tests ssl_test)
add_executable(decrepit_test ${DECREPIT_TEST_SOURCES})
target_link_libraries(decrepit_test test_support_lib boringssl_gtest_main
decrepit crypto)
add_dependencies(all_tests decrepit_test)
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>
1 year ago
if(APPLE)
set(PKI_CXX_FLAGS "-fno-aligned-new")
endif()
add_library(pki ${PKI_SOURCES})
target_compile_definitions(pki PRIVATE _BORINGSSL_LIBPKI_)
target_link_libraries(pki crypto)
add_executable(pki_test ${PKI_TEST_SOURCES})
target_compile_definitions(pki_test PRIVATE _BORINGSSL_LIBPKI_)
target_link_libraries(pki_test test_support_lib boringssl_gtest_main pki crypto)
add_dependencies(all_tests pki_test)
# The PKI library requires C++17.
set_target_properties(
pki pki_test
PROPERTIES
CXX_STANDARD 17
CXX_STANDARD_REQUIRED YES
COMPILE_FLAGS "${PKI_CXX_FLAGS}")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
Use sources.cmake for test binaries 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>
1 year ago
# Historically, targets were built in subdirectories. For compatibility with
# existing tools, we, for now, copy the targets into the subdirectories. This
# will be removed sometime in 2024.
copy_post_build(crypto crypto_test urandom_test)
copy_post_build(ssl ssl_test)
copy_post_build(decrepit decrepit_test)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(FUZZ)
if(LIBFUZZER_FROM_DEPS)
file(GLOB LIBFUZZER_SOURCES "util/bot/libFuzzer/*.cpp")
add_library(Fuzzer STATIC ${LIBFUZZER_SOURCES})
# libFuzzer does not pass our aggressive warnings. It also must be built
# without -fsanitize-coverage options or clang crashes.
set_target_properties(Fuzzer PROPERTIES COMPILE_FLAGS "-Wno-shadow -Wno-format-nonliteral -Wno-missing-prototypes -fsanitize-coverage=0")
endif()
add_subdirectory(fuzz)
endif()
Put Rust binding generation behind an explicit flag and only build bindings for the targeted Arch Change-Id: I8ccd53bce0d73bd9d79f65770e544a75753ce4f8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51025 Reviewed-by: David Benjamin <davidben@google.com>
3 years ago
if(RUST_BINDINGS)
find_program(BINDGEN_EXECUTABLE bindgen)
if(NOT BINDGEN_EXECUTABLE)
message(FATAL_ERROR "Could not find bindgen but was asked to generate Rust bindings.")
else()
add_subdirectory(rust)
endif()
endif()
Condition split handshake tests on Linux in CMake. This matches the source, which only builds support for these tests on Linux. Note Android sets CMAKE_SYSTEM_NAME to "Android", so this covers the previous ANDROID check. Bug: 476 Change-Id: I41ca408706d0d0c5bb22006f4c31d51fc1267f69 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51165 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
set(HANDSHAKER_ARGS "-handshaker-path" $<TARGET_FILE:handshaker>)
endif()
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
if(FIPS)
add_custom_target(
acvp_tests
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
COMMAND ${GO_EXECUTABLE} build -o ${CMAKE_CURRENT_BINARY_DIR}/acvptool
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
boringssl.googlesource.com/boringssl/util/fipstools/acvp/acvptool
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
COMMAND ${GO_EXECUTABLE} build -o ${CMAKE_CURRENT_BINARY_DIR}/testmodulewrapper
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
boringssl.googlesource.com/boringssl/util/fipstools/acvp/acvptool/testmodulewrapper
COMMAND cd util/fipstools/acvp/acvptool/test &&
${GO_EXECUTABLE} run check_expected.go
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
-tool ${CMAKE_CURRENT_BINARY_DIR}/acvptool
-module-wrappers modulewrapper:$<TARGET_FILE:modulewrapper>,testmodulewrapper:${CMAKE_CURRENT_BINARY_DIR}/testmodulewrapper
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
-tests tests.json
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
DEPENDS modulewrapper
USES_TERMINAL)
add_custom_target(
fips_specific_tests_if_any
DEPENDS acvp_tests
)
else()
add_custom_target(fips_specific_tests_if_any)
endif()
Use file(STRINGS) to read go_tests.txt 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>
1 year ago
file(STRINGS util/go_tests.txt GO_TESTS)
Run Go tests as part of run_tests 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>
2 years ago
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS
util/go_tests.txt)
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
add_custom_target(
run_tests
Fix ninja run_tests 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>
2 years ago
COMMAND ${GO_EXECUTABLE} test ${GO_TESTS}
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
COMMAND ${GO_EXECUTABLE} run util/all_tests.go -build-dir
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
${CMAKE_CURRENT_BINARY_DIR}
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
COMMAND cd ssl/test/runner &&
${GO_EXECUTABLE} test -shim-path $<TARGET_FILE:bssl_shim>
${HANDSHAKER_ARGS} ${RUNNER_ARGS}
Replace almost all instances of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR 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>
2 years ago
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
acvp: add tests This change causes the run_tests target, in FIPS builds, to run ACVP for each supported algorithm. For most of them the output can be compared against a known result. For some of them the output is too variable and they are only run to ensure that they don't have local errors. The ACVP test vectors have been trimmed significantly because they're often huge. Firstly an included tool drops all but one test from each group. Some vector sets have been manually trimmed to remove tests that cause variable output. Change-Id: Iff73851e3d47813041cc7ea6d881282750274940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44746 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
DEPENDS all_tests bssl_shim handshaker fips_specific_tests_if_any
acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
4 years ago
USES_TERMINAL)
Add CMake install rules. This creates an install directory under the top level source directory. The install contains a CMake config file that produces variables and targets compatible with FindOpenSSL, or the directory can be scanned by FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with third-party dependencies that find an SSL implementation via CMake. Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
Don't include custom builds of libc++ in CMake installs 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>
2 years ago
install_if_enabled(DIRECTORY include/ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
Add CMake install rules. This creates an install directory under the top level source directory. The install contains a CMake config file that produces variables and targets compatible with FindOpenSSL, or the directory can be scanned by FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with third-party dependencies that find an SSL implementation via CMake. Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
Don't include custom builds of libc++ in CMake installs 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>
2 years ago
install_if_enabled(EXPORT OpenSSLTargets
Add CMake install rules. This creates an install directory under the top level source directory. The install contains a CMake config file that produces variables and targets compatible with FindOpenSSL, or the directory can be scanned by FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with third-party dependencies that find an SSL implementation via CMake. Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
3 years ago
FILE OpenSSLTargets.cmake
NAMESPACE OpenSSL::
DESTINATION lib/cmake/OpenSSL
)
Don't include custom builds of libc++ in CMake installs 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>
2 years ago
install_if_enabled(FILES cmake/OpenSSLConfig.cmake DESTINATION lib/cmake/OpenSSL)