github-repos/benchmark
1
0
Fork 0
mirror of https://github.com/google/benchmark.git synced 2024-12-28 05:20:14 +08:00
Code Issues Packages Projects Releases Wiki Activity
fe5a386b40
benchmark/cmake/GoogleTest.cmake

53 lines
2.2 KiB
CMake
Raw Normal View History

CMake: codedrop of googletest cmake magic from me (#809) https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to some linking issue between googletest and threading libraries. I suspect that is mostly happening because of the, uhm, intentionally extremely twisted-in-the-brains approach that is being used to actually build the library as part of the buiild, except without actually building it as part of the build. If we do actually build it as part of the build, then all the transitive dependencies should magically be in order, and maybe everything will just work. This new version of cmake magic was written by me in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake.in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
2019-04-30 18:36:29 +08:00
# Download and unpack googletest at configure time
set(GOOGLETEST_PREFIX "${benchmark_BINARY_DIR}/third_party/googletest")
configure_file(${benchmark_SOURCE_DIR}/cmake/GoogleTest.cmake.in ${GOOGLETEST_PREFIX}/CMakeLists.txt @ONLY)
Allow setting GOOGLETEST_PATH cmake argument. Fixes #867 (#868) In `cmake/GoogleTest.cmake`, GOOGLETEST_PATH is default-initialized, but that init forgot to account for the fact that the patch is explicitly supposed to be user-configurable. By passing `CACHE` to `set()` we avoid that error.
2019-09-16 01:25:32 +08:00
set(GOOGLETEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}/googletest" CACHE PATH "") # Mind the quotes
CMake: codedrop of googletest cmake magic from me (#809) https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to some linking issue between googletest and threading libraries. I suspect that is mostly happening because of the, uhm, intentionally extremely twisted-in-the-brains approach that is being used to actually build the library as part of the buiild, except without actually building it as part of the build. If we do actually build it as part of the build, then all the transitive dependencies should magically be in order, and maybe everything will just work. This new version of cmake magic was written by me in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake.in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
2019-04-30 18:36:29 +08:00
execute_process(COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}"
CMake: avoid incorrect extra "" around the GOOGLETEST_PATH. It was looking in `"<...>/googlebenchmark/build/third_party/googletest"`, with these extra `"` quotes, and wasn't finding anything..
2019-05-01 00:32:38 +08:00
-DALLOW_DOWNLOADING_GOOGLETEST=${BENCHMARK_DOWNLOAD_DEPENDENCIES} -DGOOGLETEST_PATH:PATH=${GOOGLETEST_PATH} .
CMake: codedrop of googletest cmake magic from me (#809) https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to some linking issue between googletest and threading libraries. I suspect that is mostly happening because of the, uhm, intentionally extremely twisted-in-the-brains approach that is being used to actually build the library as part of the buiild, except without actually building it as part of the build. If we do actually build it as part of the build, then all the transitive dependencies should magically be in order, and maybe everything will just work. This new version of cmake magic was written by me in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake.in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
2019-04-30 18:36:29 +08:00
RESULT_VARIABLE result
WORKING_DIRECTORY ${GOOGLETEST_PREFIX}
)
if(result)
message(FATAL_ERROR "CMake step for googletest failed: ${result}")
endif()
execute_process(
COMMAND ${CMAKE_COMMAND} --build .
RESULT_VARIABLE result
WORKING_DIRECTORY ${GOOGLETEST_PREFIX}
)
if(result)
message(FATAL_ERROR "Build step for googletest failed: ${result}")
endif()
# Prevent overriding the parent project's compiler/linker
# settings on Windows
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
include(${GOOGLETEST_PREFIX}/googletest-paths.cmake)
so much for googletest not failing any more
2021-08-11 22:10:02 +08:00
# googletest doesn't seem to want to stay build warning clean so let's not hurt ourselves.
Suppress GoogleTest warnings on windows (MSVC) too. (#1320) Fixes #1209
2022-01-13 22:21:43 +08:00
if (MSVC)
add_compile_options(/wd4244 /wd4722)
else()
add_compile_options(-w)
endif()
so much for googletest not failing any more
2021-08-11 22:10:02 +08:00
CMake: codedrop of googletest cmake magic from me (#809) https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to some linking issue between googletest and threading libraries. I suspect that is mostly happening because of the, uhm, intentionally extremely twisted-in-the-brains approach that is being used to actually build the library as part of the buiild, except without actually building it as part of the build. If we do actually build it as part of the build, then all the transitive dependencies should magically be in order, and maybe everything will just work. This new version of cmake magic was written by me in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake.in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
2019-04-30 18:36:29 +08:00
# Add googletest directly to our build. This defines
# the gtest and gtest_main targets.
add_subdirectory(${GOOGLETEST_SOURCE_DIR}
${GOOGLETEST_BINARY_DIR}
EXCLUDE_FROM_ALL)
Add clang-tidy check (#1290) * Add clang-tidy.yml and .clang-tidy * Add mention to authors/contributors * Temp fix 2 clang-tidy issues * Enable clang-tidy on pull requests * Exclude gtest source files from clang-tidy
2021-11-25 23:47:44 +08:00
if(NOT DEFINED GTEST_COMPILE_COMMANDS)
set(GTEST_COMPILE_COMMANDS ON)
endif()
set_target_properties(gtest PROPERTIES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES $<TARGET_PROPERTY:gtest,INTERFACE_INCLUDE_DIRECTORIES> EXPORT_COMPILE_COMMANDS ${GTEST_COMPILE_COMMANDS})
set_target_properties(gtest_main PROPERTIES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES $<TARGET_PROPERTY:gtest_main,INTERFACE_INCLUDE_DIRECTORIES> EXPORT_COMPILE_COMMANDS ${GTEST_COMPILE_COMMANDS})
set_target_properties(gmock PROPERTIES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES $<TARGET_PROPERTY:gmock,INTERFACE_INCLUDE_DIRECTORIES> EXPORT_COMPILE_COMMANDS ${GTEST_COMPILE_COMMANDS})
set_target_properties(gmock_main PROPERTIES INTERFACE_SYSTEM_INCLUDE_DIRECTORIES $<TARGET_PROPERTY:gmock_main,INTERFACE_INCLUDE_DIRECTORIES> EXPORT_COMPILE_COMMANDS ${GTEST_COMPILE_COMMANDS})
Reference in New Issue Copy Permalink