eson/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #1 from google/master

Browse Source 
Syncing my branch
This commit is contained in:
Sam Roth 2017-01-23 13:49:32 -05:00 committed by GitHub
commit 3134af23d7
8 changed files with 127 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CMakeLists.txt
View File

@ -1,4 +1,4 @@
cmake_minimum_required(VERSION 2.6.2)
cmake_minimum_required(VERSION 2.6.4)
project( googletest-distribution )

2
googlemock/CMakeLists.txt
View File

@ -38,7 +38,7 @@ endif()
# ${gmock_BINARY_DIR}.
# Language "C" is required for find_package(Threads).
project(gmock CXX C)
cmake_minimum_required(VERSION 2.6.2)
cmake_minimum_required(VERSION 2.6.4)
if (COMMAND set_up_hermetic_build)
set_up_hermetic_build()

10
googlemock/README.md
View File

@ -125,6 +125,14 @@ build Google Mock and its tests, which has further requirements:
### Building Google Mock ###
If you have CMake available, it is recommended that you follow the
[build instructions][gtest_cmakebuild]
as described for Google Test. If are using Google Mock with an
existing CMake project, the section
[Incorporating Into An Existing CMake Project][gtest_incorpcmake]
may be of particular interest. Otherwise, the following sections
detail how to build Google Mock without CMake.
#### Preparing to Build (Unix only) ####
If you are using a Unix system and plan to use the GNU Autotools build
@ -331,3 +339,5 @@ patch.
Happy testing!
[gtest_readme]: ../googletest/README.md "googletest"
[gtest_cmakebuild]: ../googletest/README.md#using-cmake "Using CMake"
[gtest_incorpcmake]: ../googletest/README.md#incorporating-into-an-existing-cmake-project "Incorporating Into An Existing CMake Project"

2
googlemock/docs/CookBook.md
View File

@ -218,7 +218,7 @@ per-function syntactic overhead will be much lower.
If you are concerned about the performance overhead incurred by
virtual functions, and profiling confirms your concern, you can
combine this with the recipe for [mocking non-virtual methods](#Mocking_Nonvirtual_Methods.md).
combine this with the recipe for [mocking non-virtual methods](#mocking-nonvirtual-methods).
## The Nice, the Strict, and the Naggy ##

2
googletest/CMakeLists.txt
View File

@ -45,7 +45,7 @@ endif()
# ${gtest_BINARY_DIR}.
# Language "C" is required for find_package(Threads).
project(gtest CXX C)
cmake_minimum_required(VERSION 2.6.2)
cmake_minimum_required(VERSION 2.6.4)
if (COMMAND set_up_hermetic_build)
set_up_hermetic_build()

107
googletest/README.md
View File

@ -59,7 +59,13 @@ cross-platform.). If you don't have CMake installed already, you can
download it for free from <http://www.cmake.org/>.
CMake works by generating native makefiles or build projects that can
be used in the compiler environment of your choice. The typical
be used in the compiler environment of your choice. You can either
build Google Test as a standalone project or it can be incorporated
into an existing CMake build for another project.
#### Standalone CMake Project ####
When building Google Test as a standalone project, the typical
workflow starts with:
mkdir mybuild # Create a directory to hold the build output.
@ -80,13 +86,110 @@ using Visual Studio.
On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated.
#### Incorporating Into An Existing CMake Project ####
If you want to use gtest in a project which already uses CMake, then a
more robust and flexible approach is to build gtest as part of that
project directly. This is done by making the GoogleTest source code
available to the main build and adding it using CMake's
`add_subdirectory()` command. This has the significant advantage that
the same compiler and linker settings are used between gtest and the
rest of your project, so issues associated with using incompatible
libraries (eg debug/release), etc. are avoided. This is particularly
useful on Windows. Making GoogleTest's source code available to the
main build can be done a few different ways:
* Download the GoogleTest source code manually and place it at a
known location. This is the least flexible approach and can make
it more difficult to use with continuous integration systems, etc.
* Embed the GoogleTest source code as a direct copy in the main
project's source tree. This is often the simplest approach, but is
also the hardest to keep up to date. Some organizations may not
permit this method.
* Add GoogleTest as a git submodule or equivalent. This may not
always be possible or appropriate. Git submodules, for example,
have their own set of advantages and drawbacks.
* Use CMake to download GoogleTest as part of the build's configure
step. This is just a little more complex, but doesn't have the
limitations of the other methods.
The last of the above methods is implemented with a small piece
of CMake code in a separate file (e.g. `CMakeLists.txt.in`) which
is copied to the build area and then invoked as a sub-build
_during the CMake stage_. That directory is then pulled into the
main build with `add_subdirectory()`. For example:
New file `CMakeLists.txt.in`:
cmake_minimum_required(VERSION 2.8.2)
project(googletest-download NONE)
include(ExternalProject)
ExternalProject_Add(googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG master
SOURCE_DIR "${CMAKE_BINARY_DIR}/googletest-src"
BINARY_DIR "${CMAKE_BINARY_DIR}/googletest-build"
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
TEST_COMMAND ""
)
Existing build's `CMakeLists.txt`:
# Download and unpack googletest at configure time
configure_file(CMakeLists.txt.in googletest-download/CMakeLists.txt)
execute_process(COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" .
RESULT_VARIABLE result
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download )
if(result)
message(FATAL_ERROR "CMake step for googletest failed: ${result}")
endif()
execute_process(COMMAND ${CMAKE_COMMAND} --build .
RESULT_VARIABLE result
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download )
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)
# Add googletest directly to our build. This defines
# the gtest and gtest_main targets.
add_subdirectory(${CMAKE_BINARY_DIR}/googletest-src
${CMAKE_BINARY_DIR}/googletest-build)
# The gtest/gtest_main targets carry header search path
# dependencies automatically when using CMake 2.8.11 or
# later. Otherwise we have to add them here ourselves.
if (CMAKE_VERSION VERSION_LESS 2.8.11)
include_directories("${gtest_SOURCE_DIR}/include")
endif()
# Now simply link against gtest or gtest_main as needed. Eg
add_executable(example example.cpp)
target_link_libraries(example gtest_main)
add_test(NAME example_test COMMAND example)
Note that this approach requires CMake 2.8.2 or later due to
its use of the `ExternalProject_Add()` command. The above
technique is discussed in more detail in
[this separate article](http://crascit.com/2015/07/25/cmake-gtest/)
which also contains a link to a fully generalized implementation
of the technique.
### Legacy Build Scripts ###
Before settling on CMake, we have been providing hand-maintained build
projects/scripts for Visual Studio, Xcode, and Autotools. While we
continue to provide them for convenience, they are not actively
maintained any more. We highly recommend that you follow the
instructions in the previous two sections to integrate Google Test
instructions in the above sections to integrate Google Test
with your existing build system.
If you still need to use the legacy build scripts, here's how:

8
googletest/include/gtest/internal/gtest-port.h
View File

@ -760,8 +760,12 @@ using ::std::tuple_size;
# if GTEST_OS_LINUX && !defined(__ia64__)
# if GTEST_OS_LINUX_ANDROID
// On Android, clone() is only available on ARM starting with Gingerbread.
# if defined(__arm__) && __ANDROID_API__ >= 9
// On Android, clone() became available at different API levels for each 32-bit
// architecture.
# if defined(__LP64__) || \
(defined(__arm__) && __ANDROID_API__ >= 9) || \
(defined(__mips__) && __ANDROID_API__ >= 12) || \
(defined(__i386__) && __ANDROID_API__ >= 17)
# define GTEST_HAS_CLONE 1
# else
# define GTEST_HAS_CLONE 0

2
googletest/test/gtest-printers_test.cc
View File

@ -211,7 +211,9 @@ using ::testing::internal::Strings;
using ::testing::internal::UniversalPrint;
using ::testing::internal::UniversalPrinter;
using ::testing::internal::UniversalTersePrint;
#if GTEST_HAS_TR1_TUPLE || GTEST_HAS_STD_TUPLE_
using ::testing::internal::UniversalTersePrintTupleFieldsToStrings;
#endif
using ::testing::internal::string;
// The hash_* classes are not part of the C++ standard. STLport