Merge branch 'master' into fix-issue-776-support-autoconf-as-submodule

4 files changed, 3 insertions, 168 deletions

diff --git a/googletest/CMakeLists.txt b/googletest/CMakeLists.txt
index 31fef2c..3b907fd 100644
--- a/googletest/CMakeLists.txt
+++ b/googletest/CMakeLists.txt
@@ -105,8 +105,8 @@ target_link_libraries(gtest_main gtest)
 # to the targets for when we are part of a parent build (ie being pulled
 # in via add_subdirectory() rather than being a standalone build).
 if (DEFINED CMAKE_VERSION AND NOT "${CMAKE_VERSION}" VERSION_LESS "2.8.11")
-  target_include_directories(gtest      INTERFACE "${gtest_SOURCE_DIR}/include")
-  target_include_directories(gtest_main INTERFACE "${gtest_SOURCE_DIR}/include")
+  target_include_directories(gtest      SYSTEM INTERFACE "${gtest_SOURCE_DIR}/include")
+  target_include_directories(gtest_main SYSTEM INTERFACE "${gtest_SOURCE_DIR}/include")
 endif()
 
 ########################################################################
diff --git a/googletest/README.md b/googletest/README.md
index f273a7d..225aba2 100644
--- a/googletest/README.md
+++ b/googletest/README.md
@@ -358,38 +358,3 @@ instead of
     TEST(SomeTest, DoesThis) { ... }
 
 in order to define a test.
-
-## Developing Google Test ##
-
-This section discusses how to make your own changes to Google Test.
-
-### Testing Google Test Itself ###
-
-To make sure your changes work as intended and don't break existing
-functionality, you'll want to compile and run Google Test's own tests.
-For that you can use CMake:
-
-    mkdir mybuild
-    cd mybuild
-    cmake -Dgtest_build_tests=ON ${GTEST_DIR}
-
-Make sure you have Python installed, as some of Google Test's tests
-are written in Python.  If the cmake command complains about not being
-able to find Python (`Could NOT find PythonInterp (missing:
-PYTHON_EXECUTABLE)`), try telling it explicitly where your Python
-executable can be found:
-
-    cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR}
-
-Next, you can build Google Test and all of its own tests.  On \*nix,
-this is usually done by 'make'.  To run the tests, do
-
-    make test
-
-All tests should pass.
-
-Normally you don't need to worry about regenerating the source files,
-unless you need to modify them.  In that case, you should modify the
-corresponding .pump files instead and run the pump.py Python script to
-regenerate them.  You can find pump.py in the [scripts/](scripts/) directory.
-Read the [Pump manual](docs/PumpManual.md) for how to use it.
diff --git a/googletest/docs/DevGuide.md b/googletest/docs/DevGuide.md
deleted file mode 100644
index 88a3de9..0000000
--- a/googletest/docs/DevGuide.md
+++ /dev/null
@@ -1,130 +0,0 @@
-
-
-If you are interested in understanding the internals of Google Test,
-building from source, or contributing ideas or modifications to the
-project, then this document is for you.
-
-# Introduction #
-
-First, let's give you some background of the project.
-
-## Licensing ##
-
-All Google Test source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
-
-## The Google Test Community ##
-
-The Google Test community exists primarily through the [discussion group](http://groups.google.com/group/googletestframework) and the GitHub repository.
-You are definitely encouraged to contribute to the
-discussion and you can also help us to keep the effectiveness of the
-group high by following and promoting the guidelines listed here.
-
-### Please Be Friendly ###
-
-Showing courtesy and respect to others is a vital part of the Google
-culture, and we strongly encourage everyone participating in Google
-Test development to join us in accepting nothing less. Of course,
-being courteous is not the same as failing to constructively disagree
-with each other, but it does mean that we should be respectful of each
-other when enumerating the 42 technical reasons that a particular
-proposal may not be the best choice. There's never a reason to be
-antagonistic or dismissive toward anyone who is sincerely trying to
-contribute to a discussion.
-
-Sure, C++ testing is serious business and all that, but it's also
-a lot of fun. Let's keep it that way. Let's strive to be one of the
-friendliest communities in all of open source.
-
-As always, discuss Google Test in the official GoogleTest discussion group.
-You don't have to actually submit code in order to sign up. Your participation
-itself is a valuable contribution.
-
-# Working with the Code #
-
-If you want to get your hands dirty with the code inside Google Test,
-this is the section for you.
-
-## Compiling from Source ##
-
-Once you check out the code, you can find instructions on how to
-compile it in the [README](../README.md) file.
-
-## Testing ##
-
-A testing framework is of no good if itself is not thoroughly tested.
-Tests should be written for any new code, and changes should be
-verified to not break existing tests before they are submitted for
-review. To perform the tests, follow the instructions in
-[README](../README.md) and verify that there are no failures.
-
-# Contributing Code #
-
-We are excited that Google Test is now open source, and hope to get
-great patches from the community. Before you fire up your favorite IDE
-and begin hammering away at that new feature, though, please take the
-time to read this section and understand the process. While it seems
-rigorous, we want to keep a high standard of quality in the code
-base.
-
-## Contributor License Agreements ##
-
-You must sign a Contributor License Agreement (CLA) before we can
-accept any code.  The CLA protects you and us.
-
-  * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
-  * If you work for a company that wants to allow you to contribute your work to Google Test, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
-
-Follow either of the two links above to access the appropriate CLA and
-instructions for how to sign and return it.
-
-## Coding Style ##
-
-To keep the source consistent, readable, diffable and easy to merge,
-we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
-to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
-
-## Updating Generated Code ##
-
-Some of Google Test's source files are generated by the Pump tool (a
-Python script).  If you need to update such files, please modify the
-source (`foo.h.pump`) and re-generate the C++ file using Pump.  You
-can read the PumpManual for details.
-
-## Submitting Patches ##
-
-Please do submit code. Here's what you need to do:
-
-  1. A submission should be a set of changes that addresses one issue in the [issue tracker](https://github.com/google/googletest/issues). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
-  1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
-  1. Ensure that your code adheres to the [Google Test source code style](#Coding_Style.md).
-  1. Ensure that there are unit tests for your code.
-  1. Sign a Contributor License Agreement.
-  1. Create a Pull Request in the usual way.
-
-If you are a Googler, it is preferable to first create an internal change and
-have it reviewed and submitted, and then create an upstreaming pull
-request here. 
-
-## Google Test Committers ##
-
-The current members of the Google Test engineering team are the only
-committers at present. In the great tradition of eating one's own
-dogfood, we will be requiring each new Google Test engineering team
-member to earn the right to become a committer by following the
-procedures in this document, writing consistently great code, and
-demonstrating repeatedly that he or she truly gets the zen of Google
-Test.
-
-# Release Process #
-
-We follow a typical release process:
-
-  1. A release branch named `release-X.Y` is created.
-  1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
-  1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
-  1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
-  1. Go back to step 1 to create another release branch and so on.
-
----
-
-This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
diff --git a/googletest/docs/Documentation.md b/googletest/docs/Documentation.md
index 1e4c5c5..3784c8f 100644
--- a/googletest/docs/Documentation.md
+++ b/googletest/docs/Documentation.md
@@ -12,5 +12,5 @@ the respective git branch/tag).**
 
 To contribute code to Google Test, read:
 
-  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
   * [PumpManual](PumpManual.md) -- how we generate some of Google Test's source files.