Merge pull request #1 from google/master
Syncing my branch
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8d2b552..5754992 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 2.6.4)
project( googletest-distribution )
diff --git a/googlemock/CMakeLists.txt b/googlemock/CMakeLists.txt
index beb259a..9fb96a4 100644
--- a/googlemock/CMakeLists.txt
+++ b/googlemock/CMakeLists.txt
@@ -38,7 +38,7 @@
# ${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()
diff --git a/googlemock/README.md b/googlemock/README.md
index 191df69..3eb10cb 100644
--- a/googlemock/README.md
+++ b/googlemock/README.md
@@ -125,6 +125,14 @@
### 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 @@
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"
diff --git a/googlemock/docs/CookBook.md b/googlemock/docs/CookBook.md
index c52f100..0460d35 100644
--- a/googlemock/docs/CookBook.md
+++ b/googlemock/docs/CookBook.md
@@ -218,7 +218,7 @@
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 ##
diff --git a/googletest/CMakeLists.txt b/googletest/CMakeLists.txt
index 621d0f0..36d0a9e 100644
--- a/googletest/CMakeLists.txt
+++ b/googletest/CMakeLists.txt
@@ -45,7 +45,7 @@
# ${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()
diff --git a/googletest/README.md b/googletest/README.md
index edd4408..0a3474c 100644
--- a/googletest/README.md
+++ b/googletest/README.md
@@ -59,7 +59,13 @@
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 @@
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:
diff --git a/googletest/include/gtest/internal/gtest-port.h b/googletest/include/gtest/internal/gtest-port.h
index 860aaaf..0d53ad2 100644
--- a/googletest/include/gtest/internal/gtest-port.h
+++ b/googletest/include/gtest/internal/gtest-port.h
@@ -760,8 +760,12 @@
# 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
diff --git a/googletest/test/gtest-printers_test.cc b/googletest/test/gtest-printers_test.cc
index 3e97cc2..af69f28 100644
--- a/googletest/test/gtest-printers_test.cc
+++ b/googletest/test/gtest-printers_test.cc
@@ -211,7 +211,9 @@
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
