kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
6effbf24bc
boringssl/decrepit/CMakeLists.txt

48 lines
884 B
CMake
Raw Normal View History

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
include_directories(../include)
Add decrepit, initially containing CAST and Blowfish. decrepit will contain algorithms that we really wish didn't exist any longer. It won't be built by default in Chromium etc, but the code will exist for crummy code that still needs it. Change-Id: Ic307f5f0a69efe9e0a5fd54052f49d219e90dcdd
2015-02-03 18:45:12 +00:00
add_library(
decrepit
Flatten the decrepit target. https://boringssl-review.googlesource.com/c/boringssl/+/31364 wants to add a dependency to each target, which is much easier with fewer of them. Start with decrepit. Change-Id: Ib3777063d545dfebe3e2b8448eb7e5bbb5c3aaac Reviewed-on: https://boringssl-review.googlesource.com/31584 Reviewed-by: Adam Langley <agl@google.com>
2018-09-05 21:12:31 +01:00
bio/base64_bio.c
blowfish/blowfish.c
cast/cast.c
cast/cast_tables.c
cfb/cfb.c
des/cfb64ede.c
dh/dh_decrepit.c
dsa/dsa_decrepit.c
evp/dss1.c
evp/evp_do_all.c
obj/obj_decrepit.c
rc4/rc4_decrepit.c
ripemd/ripemd.c
rsa/rsa_decrepit.c
ssl/ssl_decrepit.c
x509/x509_decrepit.c
xts/xts.c
Add decrepit, initially containing CAST and Blowfish. decrepit will contain algorithms that we really wish didn't exist any longer. It won't be built by default in Chromium etc, but the code will exist for crummy code that still needs it. Change-Id: Ic307f5f0a69efe9e0a5fd54052f49d219e90dcdd
2015-02-03 18:45:12 +00:00
)
Fix shared library build on OS X. It seems OS X actually cares about symbol resolution and dependencies when you create a dylib. Probably because they do two-level name resolution. (Obligatory disclaimer: BoringSSL does not have a stable ABI and is thus not suitable for a traditional system-wide library.) BUG=539603 Change-Id: Ic26c4ad23840fe6c1f4825c44671e74dd2e33870 Reviewed-on: https://boringssl-review.googlesource.com/6131 Reviewed-by: Adam Langley <alangley@gmail.com>
2015-10-06 02:32:10 +01:00
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
add_dependencies(decrepit global_target)
Banish SSL_add_dir_cert_subjects_to_stack and OPENSSL_DIR_CTX to decrepit. There was only one function that required BoringSSL to know how to read directories. Unfortunately, it does have some callers and it's not immediately obvious whether the code is unreachable. Rather than worry about that, just toss it all into decrepit. In doing so, do away with the Windows and PNaCl codepaths. Only implement OPENSSL_DIR_CTX on Linux. Change-Id: Ie64d20254f2f632fadc3f248bbf5a8293ab2b451 Reviewed-on: https://boringssl-review.googlesource.com/7661 Reviewed-by: Adam Langley <agl@google.com>
2016-04-01 23:37:07 +01:00
target_link_libraries(decrepit crypto ssl)
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_executable(
decrepit_test
Add EVP_CIPHER support for Blowfish and CAST to decrepit. Postgres contains a “pqcrypto” module that showcases the worst of 90's crypto, including Blowfish and CAST5 in CFB, CBC, and ECB modes. (Also, 64-bit keys for both of those.) In order to minimise the patching needed to build Postgres, put these things in decrepit. Change-Id: I8390c5153dd7227eef07293a4363878d79df8b21 Reviewed-on: https://boringssl-review.googlesource.com/c/34044 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2019-01-03 19:23:54 +00:00
blowfish/blowfish_test.cc
cast/cast_test.cc
Add EVP AES-128 CFB128 support via decrepit. Change-Id: I37a438b5b4b18d18756ba4aeb9f8548caa333981 Reviewed-on: https://boringssl-review.googlesource.com/20384 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-09-14 18:14:34 +01:00
cfb/cfb_test.cc
Add EVP_CIPHER support for Blowfish and CAST to decrepit. Postgres contains a “pqcrypto” module that showcases the worst of 90's crypto, including Blowfish and CAST5 in CFB, CBC, and ECB modes. (Also, 64-bit keys for both of those.) In order to minimise the patching needed to build Postgres, put these things in decrepit. Change-Id: I8390c5153dd7227eef07293a4363878d79df8b21 Reviewed-on: https://boringssl-review.googlesource.com/c/34044 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2019-01-03 19:23:54 +00:00
ripemd/ripemd_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
Rename all googletest CMake targets CMake targets are visible globally but gtest_main has boringssl-specific behavior that isn't appropriate for general use. This change makes it possible to use boringssl and abseil-cpp in the same project (since abseil-cpp expects gtest_main to exist and be useful for its own tests). Change-Id: Icc81c11b8bb4b1e21cea7c9fa725b6c082bd5369 Reviewed-on: https://boringssl-review.googlesource.com/24604 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>
2018-01-04 07:07:58 +00:00
$<TARGET_OBJECTS:boringssl_gtest_main>
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:test_support>
)
Support symbol prefixes - In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
add_dependencies(decrepit_test global_target)
Rename all googletest CMake targets CMake targets are visible globally but gtest_main has boringssl-specific behavior that isn't appropriate for general use. This change makes it possible to use boringssl and abseil-cpp in the same project (since abseil-cpp expects gtest_main to exist and be useful for its own tests). Change-Id: Icc81c11b8bb4b1e21cea7c9fa725b6c082bd5369 Reviewed-on: https://boringssl-review.googlesource.com/24604 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>
2018-01-04 07:07:58 +00:00
target_link_libraries(decrepit_test crypto decrepit boringssl_gtest)
Align on a single CMake style. We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10 16:30:55 +01:00
if(WIN32)
Convert bio_test to GTest. BUG=129 Change-Id: Iaf07075afaa2ea447e19a8c53ec0d29560d625b3 Reviewed-on: https://boringssl-review.googlesource.com/14207 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-03-09 06:13:07 +00:00
target_link_libraries(decrepit_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 decrepit_test)
Reference in New Issue Copy Permalink