Improve the tutorial that may be confusing

1 files changed, 28 insertions, 20 deletions

diff --git a/googletest/README.md b/googletest/README.md
index 8520549..4ab3cb2 100644
--- a/googletest/README.md
+++ b/googletest/README.md
@@ -24,17 +24,20 @@ another project.
 When building Google Test as a standalone project, the typical workflow starts
 with:
 
-    mkdir mybuild       # Create a directory to hold the build output.
-    cd mybuild
-    cmake ${GTEST_DIR}  # Generate native build scripts.
+    git clone https://github.com/google/googletest.git -b release-1.10.0
+    cd googletest
+    mkdir build          # Create a directory to hold the build output.
+    cd build
+    cmake ..             # Generate native build scripts for Google Test
 
-If you want to build Google Test's samples, you should replace the last command
-with
+If you are on a \*nix system, you should now see a Makefile in the current
+directory. Just type `make` to build gtest.
 
-    cmake -Dgtest_build_samples=ON ${GTEST_DIR}
+    make
 
-If you are on a \*nix system, you should now see a Makefile in the current
-directory. Just type 'make' to build gtest.
+And if you are a system administrator, you can simply install Google Test.
+
+    sudo make install    # Install in /usr/local/ by default
 
 If you use Windows and have Visual Studio installed, a `gtest.sln` file and
 several `.vcproj` files will be created. You can then build them using Visual
@@ -44,26 +47,31 @@ 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
+The easiest way to use Google Test is importing installed libraries and headers.
+
+* Import Google Test by using `find_package` (or `pkg_check_modules`).
+  For example, if `find_package(GTest CONFIG REQUIRED)` is succeed,
+  you can use the libraries as  `GTest::gtest`, `GTest::gmock`.
+
+And a more robust and flexible approach is to build gtest as part of that project
+directly. This is done by making the Google Test 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 Google Test'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
+*   Download the Google Test 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
+*   Embed the Google Test 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
+*   Add Google Test 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
+*   Use CMake to download Google Test 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.