Merge remote-tracking branch 'github_google/master' into master-github_frosteyes

6 files changed, 120 insertions, 10 deletions

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 @@ 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()
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 @@ 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:
diff --git a/googletest/include/gtest/gtest-typed-test.h b/googletest/include/gtest/gtest-typed-test.h
index 5f69d56..20726b2 100644
--- a/googletest/include/gtest/gtest-typed-test.h
+++ b/googletest/include/gtest/gtest-typed-test.h
@@ -241,9 +241,10 @@ INSTANTIATE_TYPED_TEST_CASE_P(My, FooTest, MyTypes);
   namespace GTEST_CASE_NAMESPACE_(CaseName) { \
   typedef ::testing::internal::Templates<__VA_ARGS__>::type gtest_AllTests_; \
   } \
-  static const char* const GTEST_REGISTERED_TEST_NAMES_(CaseName) = \
-      GTEST_TYPED_TEST_CASE_P_STATE_(CaseName).VerifyRegisteredTestNames(\
-          __FILE__, __LINE__, #__VA_ARGS__)
+  static const char* const GTEST_REGISTERED_TEST_NAMES_(CaseName) \
+      GTEST_ATTRIBUTE_UNUSED_ = \
+          GTEST_TYPED_TEST_CASE_P_STATE_(CaseName).VerifyRegisteredTestNames(\
+              __FILE__, __LINE__, #__VA_ARGS__)
 
 // The 'Types' template argument below must have spaces around it
 // since some compilers may choke on '>>' when passing a template
diff --git a/googletest/include/gtest/internal/gtest-port.h b/googletest/include/gtest/internal/gtest-port.h
index 92f4c11..0d53ad2 100644
--- a/googletest/include/gtest/internal/gtest-port.h
+++ b/googletest/include/gtest/internal/gtest-port.h
@@ -396,7 +396,7 @@
 #  include <io.h>
 # endif
 // In order to avoid having to include <windows.h>, use forward declaration
-#if GTEST_OS_WINDOWS_MINGW
+#if GTEST_OS_WINDOWS_MINGW && !defined(__MINGW64_VERSION_MAJOR)
 // MinGW defined _CRITICAL_SECTION and _RTL_CRITICAL_SECTION as two
 // separate (equivalent) structs, instead of using typedef
 typedef struct _CRITICAL_SECTION GTEST_CRITICAL_SECTION;
@@ -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
diff --git a/googletest/test/gtest-port_test.cc b/googletest/test/gtest-port_test.cc
index 05f8821..c5067a4 100644
--- a/googletest/test/gtest-port_test.cc
+++ b/googletest/test/gtest-port_test.cc
@@ -1295,7 +1295,7 @@ TEST(WindowsTypesTest, HANDLEIsVoidStar) {
   StaticAssertTypeEq<HANDLE, void*>();
 }
 
-#if GTEST_OS_WINDOWS_MINGW
+#if GTEST_OS_WINDOWS_MINGW && !defined(__MINGW64_VERSION_MAJOR)
 TEST(WindowsTypesTest, _CRITICAL_SECTIONIs_CRITICAL_SECTION) {
   StaticAssertTypeEq<CRITICAL_SECTION, _CRITICAL_SECTION>();
 }
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::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