boringssl/crypto/CMakeLists.txt

276 lines
6.5 KiB
CMake
Raw Normal View History

include_directories(../include)
if(NOT OPENSSL_NO_ASM)
if(UNIX)
if (${ARCH} STREQUAL "aarch64")
# The "armx" Perl scripts look for "64" in the style argument
# in order to decide whether to generate 32- or 64-bit asm.
if (APPLE)
set(PERLASM_STYLE ios64)
else()
set(PERLASM_STYLE linux64)
endif()
elseif (${ARCH} STREQUAL "arm")
if (APPLE)
set(PERLASM_STYLE ios32)
else()
set(PERLASM_STYLE linux32)
endif()
elseif (${ARCH} STREQUAL "ppc64le")
set(PERLASM_STYLE linux64le)
else()
if (${ARCH} STREQUAL "x86")
set(PERLASM_FLAGS "-fPIC -DOPENSSL_IA32_SSE2")
endif()
if (APPLE)
set(PERLASM_STYLE macosx)
else()
set(PERLASM_STYLE elf)
endif()
endif()
set(ASM_EXT S)
enable_language(ASM)
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -Wa,--noexecstack")
# 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()
# CMake does not add -isysroot and -arch flags to assembly.
if (APPLE)
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()
else()
if (${ARCH} STREQUAL "x86_64")
set(PERLASM_STYLE nasm)
else()
set(PERLASM_STYLE win32n)
set(PERLASM_FLAGS "-DOPENSSL_IA32_SSE2")
endif()
# On Windows, we use the NASM output, specifically built with Yasm.
set(ASM_EXT asm)
enable_language(ASM_NASM)
endif()
endif()
function(perlasm dest src)
add_custom_command(
OUTPUT ${dest}
COMMAND ${PERL_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/${src} ${PERLASM_STYLE} ${PERLASM_FLAGS} ${ARGN} ${dest}
DEPENDS
${src}
${PROJECT_SOURCE_DIR}/crypto/perlasm/arm-xlate.pl
Add PPC64LE assembly for AES-GCM. This change adds AES and GHASH assembly from upstream, with the aim of speeding up AES-GCM. The PPC64LE assembly matches the interface of the ARMv8 assembly so I've changed the prefix of both sets of asm functions to be the same ("aes_hw_"). Otherwise, the new assmebly files and Perlasm match exactly those from upstream's c536b6be1a (from their master branch). Before: Did 1879000 AES-128-GCM (16 bytes) seal operations in 1000428us (1878196.1 ops/sec): 30.1 MB/s Did 61000 AES-128-GCM (1350 bytes) seal operations in 1006660us (60596.4 ops/sec): 81.8 MB/s Did 11000 AES-128-GCM (8192 bytes) seal operations in 1072649us (10255.0 ops/sec): 84.0 MB/s Did 1665000 AES-256-GCM (16 bytes) seal operations in 1000591us (1664016.6 ops/sec): 26.6 MB/s Did 52000 AES-256-GCM (1350 bytes) seal operations in 1006971us (51640.0 ops/sec): 69.7 MB/s Did 8840 AES-256-GCM (8192 bytes) seal operations in 1013294us (8724.0 ops/sec): 71.5 MB/s After: Did 4994000 AES-128-GCM (16 bytes) seal operations in 1000017us (4993915.1 ops/sec): 79.9 MB/s Did 1389000 AES-128-GCM (1350 bytes) seal operations in 1000073us (1388898.6 ops/sec): 1875.0 MB/s Did 319000 AES-128-GCM (8192 bytes) seal operations in 1000101us (318967.8 ops/sec): 2613.0 MB/s Did 4668000 AES-256-GCM (16 bytes) seal operations in 1000149us (4667304.6 ops/sec): 74.7 MB/s Did 1202000 AES-256-GCM (1350 bytes) seal operations in 1000646us (1201224.0 ops/sec): 1621.7 MB/s Did 269000 AES-256-GCM (8192 bytes) seal operations in 1002804us (268247.8 ops/sec): 2197.5 MB/s Change-Id: Id848562bd4e1aa79a4683012501dfa5e6c08cfcc Reviewed-on: https://boringssl-review.googlesource.com/11262 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-23 20:47:24 +01:00
${PROJECT_SOURCE_DIR}/crypto/perlasm/ppc-xlate.pl
${PROJECT_SOURCE_DIR}/crypto/perlasm/x86_64-xlate.pl
${PROJECT_SOURCE_DIR}/crypto/perlasm/x86asm.pl
${PROJECT_SOURCE_DIR}/crypto/perlasm/x86gas.pl
${PROJECT_SOURCE_DIR}/crypto/perlasm/x86masm.pl
${PROJECT_SOURCE_DIR}/crypto/perlasm/x86nasm.pl
WORKING_DIRECTORY .
)
endfunction()
# Level 0.1 - depends on nothing outside this set.
add_subdirectory(stack)
add_subdirectory(lhash)
add_subdirectory(err)
add_subdirectory(buf)
add_subdirectory(base64)
add_subdirectory(bytestring)
add_subdirectory(pool)
# Level 0.2 - depends on nothing but itself
add_subdirectory(rc4)
add_subdirectory(conf)
2014-06-20 20:00:00 +01:00
add_subdirectory(chacha)
add_subdirectory(poly1305)
add_subdirectory(curve25519)
# Level 1, depends only on 0.*
add_subdirectory(digest_extra)
add_subdirectory(cipher_extra)
add_subdirectory(rand_extra)
add_subdirectory(bio)
add_subdirectory(bn_extra)
add_subdirectory(obj)
add_subdirectory(asn1)
# Level 2
add_subdirectory(engine)
add_subdirectory(dh)
add_subdirectory(dsa)
add_subdirectory(rsa_extra)
add_subdirectory(ec_extra)
add_subdirectory(ecdh)
add_subdirectory(ecdsa_extra)
# Level 3
add_subdirectory(cmac)
add_subdirectory(evp)
add_subdirectory(hkdf)
add_subdirectory(pem)
add_subdirectory(x509)
add_subdirectory(x509v3)
# Level 4
add_subdirectory(pkcs7)
add_subdirectory(pkcs8)
# Test support code
add_subdirectory(test)
add_subdirectory(fipsmodule)
add_library(
crypto_base
OBJECT
Rewrite ARM feature detection. This removes the thread-unsafe SIGILL-based detection and the multi-consumer-hostile CRYPTO_set_NEON_capable API. (Changing OPENSSL_armcap_P after initialization is likely to cause problems.) The right way to detect ARM features on Linux is getauxval. On aarch64, we should be able to rely on this, so use it straight. Split this out into its own file. The #ifdefs in the old cpu-arm.c meant it shared all but no code with its arm counterpart anyway. Unfortunately, various versions of Android have different missing APIs, so, on arm, we need a series of workarounds. Previously, we used a SIGILL fallback based on OpenSSL's logic, but this is inherently not thread-safe. (SIGILL also does not tell us if the OS knows how to save and restore NEON state.) Instead, base the behavior on Android NDK's cpu-features library, what Chromium currently uses with CRYPTO_set_NEON_capable: - Android before API level 20 does not provide getauxval. Where missing, we can read from /proc/self/auxv. - On some versions of Android, /proc/self/auxv is also not readable, so use /proc/cpuinfo's Features line. - Linux only advertises optional features in /proc/cpuinfo. ARMv8 makes NEON mandatory, so /proc/cpuinfo can't be used without additional effort. Finally, we must blacklist a particular chip because the NEON unit is broken (https://crbug.com/341598). Unfortunately, this means CRYPTO_library_init now depends on /proc being available, which will require some care with Chromium's sandbox. The simplest solution is to just call CRYPTO_library_init before entering the sandbox. It's worth noting that Chromium's current EnsureOpenSSLInit function already depends on /proc/cpuinfo to detect the broken CPU, by way of base::CPU. android_getCpuFeatures also interally depends on it. We were already relying on both of those being stateful and primed prior to entering the sandbox. BUG=chromium:589200 Change-Id: Ic5d1c341aab5a614eb129d8aa5ada2809edd6af8 Reviewed-on: https://boringssl-review.googlesource.com/7506 Reviewed-by: David Benjamin <davidben@google.com>
2016-03-01 22:35:47 +00:00
cpu-aarch64-linux.c
cpu-arm.c
cpu-arm-linux.c
cpu-intel.c
Add PPC64LE assembly for AES-GCM. This change adds AES and GHASH assembly from upstream, with the aim of speeding up AES-GCM. The PPC64LE assembly matches the interface of the ARMv8 assembly so I've changed the prefix of both sets of asm functions to be the same ("aes_hw_"). Otherwise, the new assmebly files and Perlasm match exactly those from upstream's c536b6be1a (from their master branch). Before: Did 1879000 AES-128-GCM (16 bytes) seal operations in 1000428us (1878196.1 ops/sec): 30.1 MB/s Did 61000 AES-128-GCM (1350 bytes) seal operations in 1006660us (60596.4 ops/sec): 81.8 MB/s Did 11000 AES-128-GCM (8192 bytes) seal operations in 1072649us (10255.0 ops/sec): 84.0 MB/s Did 1665000 AES-256-GCM (16 bytes) seal operations in 1000591us (1664016.6 ops/sec): 26.6 MB/s Did 52000 AES-256-GCM (1350 bytes) seal operations in 1006971us (51640.0 ops/sec): 69.7 MB/s Did 8840 AES-256-GCM (8192 bytes) seal operations in 1013294us (8724.0 ops/sec): 71.5 MB/s After: Did 4994000 AES-128-GCM (16 bytes) seal operations in 1000017us (4993915.1 ops/sec): 79.9 MB/s Did 1389000 AES-128-GCM (1350 bytes) seal operations in 1000073us (1388898.6 ops/sec): 1875.0 MB/s Did 319000 AES-128-GCM (8192 bytes) seal operations in 1000101us (318967.8 ops/sec): 2613.0 MB/s Did 4668000 AES-256-GCM (16 bytes) seal operations in 1000149us (4667304.6 ops/sec): 74.7 MB/s Did 1202000 AES-256-GCM (1350 bytes) seal operations in 1000646us (1201224.0 ops/sec): 1621.7 MB/s Did 269000 AES-256-GCM (8192 bytes) seal operations in 1002804us (268247.8 ops/sec): 2197.5 MB/s Change-Id: Id848562bd4e1aa79a4683012501dfa5e6c08cfcc Reviewed-on: https://boringssl-review.googlesource.com/11262 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-23 20:47:24 +01:00
cpu-ppc64le.c
crypto.c
ex_data.c
mem.c
refcount_c11.c
refcount_lock.c
thread.c
thread_none.c
thread_pthread.c
thread_win.c
)
if(FIPS_DELOCATE)
SET_SOURCE_FILES_PROPERTIES(fipsmodule/bcm.o PROPERTIES EXTERNAL_OBJECT true)
SET_SOURCE_FILES_PROPERTIES(fipsmodule/bcm.o PROPERTIES GENERATED true)
set(
CRYPTO_FIPS_OBJECTS
fipsmodule/bcm.o
)
endif()
add_library(
crypto
$<TARGET_OBJECTS:crypto_base>
$<TARGET_OBJECTS:stack>
$<TARGET_OBJECTS:lhash>
$<TARGET_OBJECTS:err>
$<TARGET_OBJECTS:base64>
$<TARGET_OBJECTS:bytestring>
$<TARGET_OBJECTS:pool>
$<TARGET_OBJECTS:fipsmodule>
$<TARGET_OBJECTS:digest_extra>
$<TARGET_OBJECTS:cipher_extra>
$<TARGET_OBJECTS:rc4>
$<TARGET_OBJECTS:conf>
$<TARGET_OBJECTS:chacha>
$<TARGET_OBJECTS:poly1305>
$<TARGET_OBJECTS:curve25519>
$<TARGET_OBJECTS:buf>
$<TARGET_OBJECTS:bn_extra>
$<TARGET_OBJECTS:bio>
$<TARGET_OBJECTS:rand_extra>
$<TARGET_OBJECTS:obj>
$<TARGET_OBJECTS:asn1>
$<TARGET_OBJECTS:engine>
$<TARGET_OBJECTS:dh>
$<TARGET_OBJECTS:dsa>
$<TARGET_OBJECTS:rsa_extra>
$<TARGET_OBJECTS:ec_extra>
$<TARGET_OBJECTS:ecdh>
$<TARGET_OBJECTS:ecdsa_extra>
$<TARGET_OBJECTS:cmac>
$<TARGET_OBJECTS:evp>
$<TARGET_OBJECTS:hkdf>
$<TARGET_OBJECTS:pem>
$<TARGET_OBJECTS:x509>
$<TARGET_OBJECTS:x509v3>
$<TARGET_OBJECTS:pkcs7>
$<TARGET_OBJECTS:pkcs8_lib>
${CRYPTO_FIPS_OBJECTS}
)
if(FIPS_DELOCATE)
add_dependencies(crypto bcm_o_target)
endif()
SET_TARGET_PROPERTIES(crypto PROPERTIES LINKER_LANGUAGE C)
if(NOT MSVC AND NOT ANDROID)
target_link_libraries(crypto pthread)
endif()
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
# TODO(davidben): Convert the remaining tests to GTest.
add_executable(
crypto_test
asn1/asn1_test.cc
base64/base64_test.cc
bio/bio_test.cc
bytestring/bytestring_test.cc
chacha/chacha_test.cc
cipher_extra/aead_test.cc
cipher_extra/cipher_test.cc
cmac/cmac_test.cc
compiler_test.cc
constant_time_test.cc
curve25519/ed25519_test.cc
curve25519/spake25519_test.cc
curve25519/x25519_test.cc
ecdh/ecdh_test.cc
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
dh/dh_test.cc
digest_extra/digest_test.cc
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
dsa/dsa_test.cc
err/err_test.cc
evp/evp_extra_test.cc
evp/evp_test.cc
evp/pbkdf_test.cc
evp/scrypt_test.cc
fipsmodule/aes/aes_test.cc
fipsmodule/bn/bn_test.cc
fipsmodule/ec/ec_test.cc
fipsmodule/ec/p256-x86_64_test.cc
fipsmodule/ecdsa/ecdsa_test.cc
fipsmodule/modes/gcm_test.cc
fipsmodule/rand/ctrdrbg_test.cc
hkdf/hkdf_test.cc
hmac_extra/hmac_test.cc
lhash/lhash_test.cc
obj/obj_test.cc
pkcs7/pkcs7_test.cc
pkcs8/pkcs8_test.cc
pkcs8/pkcs12_test.cc
poly1305/poly1305_test.cc
pool/pool_test.cc
refcount_test.cc
rsa_extra/rsa_test.cc
test/file_test_gtest.cc
thread_test.cc
x509/x509_test.cc
x509v3/tab_test.cc
x509v3/v3name_test.cc
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
$<TARGET_OBJECTS:crypto_test_data>
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
$<TARGET_OBJECTS:gtest_main>
$<TARGET_OBJECTS:test_support>
)
target_link_libraries(crypto_test crypto gtest)
if (WIN32)
target_link_libraries(crypto_test ws2_32)
endif()
Do a cursory conversion of a few tests to GTest. For now, this is the laziest conversion possible. The intent is to just get the build setup ready so that we can get everything working in our consumers. The intended end state is: - The standalone build produces three test targets, one per library: {crypto,ssl,decrepit}_tests. - Each FOO_test is made up of: FOO/**/*_test.cc crypto/test/gtest_main.cc test_support - generate_build_files.py emits variables crypto_test_sources and ssl_test_sources. These variables are populated with FindCFiles, looking for *_test.cc. - The consuming file assembles those variables into the two test targets (plus decrepit) from there. This avoids having generate_build_files.py emit actual build rules. - Our standalone builders, Chromium, and Android just run the top-level test targets using whatever GTest-based reporting story they have. In transition, we start by converting one of two tests in each library to populate the three test targets. Those are added to all_tests.json and all_tests.go hacked to handle them transparently. This keeps our standalone builder working. generate_build_files.py, to start with, populates the new source lists manually and subtracts them out of the old machinery. We emit both for the time being. When this change rolls in, we'll write all the build glue needed to build the GTest-based tests and add it to consumers' continuous builders. Next, we'll subsume a file-based test and get the consumers working with that. (I.e. make sure the GTest targets can depend on a data file.) Once that's all done, we'll be sure all this will work. At that point, we start subsuming the remaining tests into the GTest targets and, asynchronously, rewriting tests to use GTest properly rather than cursory conversion here. When all non-GTest tests are gone, the old generate_build_files.py hooks will be removed, consumers updated to not depend on them, and standalone builders converted to not rely on all_tests.go, which can then be removed. (Unless bits end up being needed as a malloc test driver. I'm thinking we'll want to do something with --gtest_filter.) As part of this CL, I've bumped the CMake requirements (for target_include_directories) and added a few suppressions for warnings that GTest doesn't pass. BUG=129 Change-Id: I881b26b07a8739cc0b52dbb51a30956908e1b71a Reviewed-on: https://boringssl-review.googlesource.com/13232 Reviewed-by: Adam Langley <agl@google.com>
2017-01-20 00:05:47 +00:00
add_dependencies(all_tests crypto_test)