aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--CONTRIBUTING.md131
-rw-r--r--README.md32
-rw-r--r--googlemock/README.md32
-rw-r--r--googlemock/docs/DevGuide.md132
-rw-r--r--googlemock/docs/Documentation.md2
-rw-r--r--googletest/README.md35
-rw-r--r--googletest/docs/DevGuide.md130
-rw-r--r--googletest/docs/Documentation.md2
8 files changed, 132 insertions, 364 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0ac02f5d..0ebdfcc6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -21,8 +21,16 @@ accept your pull requests.
## Contributing A Patch
-1. Submit an issue describing your proposed change to the repo in question.
-1. The repo owner will respond to your issue promptly.
+1. Submit an issue describing your proposed change to the
+ [issue tracker](https://github.com/google/googletest).
+1. 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. If your proposed change is accepted, and you haven't already done so, sign a
Contributor License Agreement (see details above).
1. Fork the desired repo, develop and test your code changes.
@@ -31,7 +39,122 @@ accept your pull requests.
1. Ensure that your code has an appropriate set of unit tests which all pass.
1. Submit a pull request.
+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.
+
+## The Google Test and Google Mock Communities ##
+
+The Google Test community exists primarily through the
+[discussion group](http://groups.google.com/group/googletestframework)
+and the GitHub repository.
+Likewise, the Google Mock community exists primarily through their own
+[discussion group](http://groups.google.com/group/googlemock).
+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.
+
## Style
-Samples in this repository follow the [Google C++ Style Guide](
-https://google.github.io/styleguide/cppguide.html).
+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).
+
+## Requirements for Contributors ###
+
+If you plan to contribute a patch, you need to build Google Test,
+Google Mock, and their own tests from a git checkout, which has
+further requirements:
+
+ * [Python](https://www.python.org/) v2.3 or newer (for running some of
+ the tests and re-generating certain source files from templates)
+ * [CMake](https://cmake.org/) v2.6.4 or newer
+ * [GNU Build System](https://en.wikipedia.org/wiki/GNU_Build_System)
+ including automake (>= 1.9), autoconf (>= 2.59), and
+ libtool / libtoolize.
+
+## 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.
+
+### Regenerating Source Files ##
+
+Some of Google Test's source files are generated from templates (not
+in the C++ sense) using a script.
+For example, the
+file include/gtest/internal/gtest-type-util.h.pump is used to generate
+gtest-type-util.h in the same directory.
+
+You don't need to worry about regenerating the source files
+unless you need to modify them. You would then modify the
+corresponding `.pump` files and run the '[pump.py](googletest/scripts/pump.py)'
+generator script. See the [Pump Manual](googletest/docs/PumpManual.md).
+
+## Developing Google Mock ###
+
+This section discusses how to make your own changes to Google Mock.
+
+#### Testing Google Mock 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'll need Autotools. First, make sure you have followed
+the instructions above to configure Google Mock.
+Then, create a build output directory and enter it. Next,
+
+ ${GMOCK_DIR}/configure # try --help for more info
+
+Once you have successfully configured Google Mock, the build steps are
+standard for GNU-style OSS packages.
+
+ make # Standard makefile following GNU conventions
+ make check # Builds and runs all tests - all should pass.
+
+Note that when building your project against Google Mock, you are building
+against Google Test as well. There is no need to configure Google Test
+separately.
diff --git a/README.md b/README.md
index f858833d..79363002 100644
--- a/README.md
+++ b/README.md
@@ -114,35 +114,9 @@ package (as described below):
* Mac OS X v10.4 Tiger or newer
* Xcode Developer Tools
-### Requirements for Contributors ###
+## Contributing change
-We welcome patches. If you plan to contribute a patch, you need to
-build Google Test and its own tests from a git checkout (described
-below), which has further requirements:
-
- * [Python](https://www.python.org/) v2.3 or newer (for running some of
- the tests and re-generating certain source files from templates)
- * [CMake](https://cmake.org/) v2.6.4 or newer
-
-## Regenerating Source Files ##
-
-Some of Google Test's source files are generated from templates (not
-in the C++ sense) using a script.
-For example, the
-file include/gtest/internal/gtest-type-util.h.pump is used to generate
-gtest-type-util.h in the same directory.
-
-You don't need to worry about regenerating the source files
-unless you need to modify them. You would then modify the
-corresponding `.pump` files and run the '[pump.py](googletest/scripts/pump.py)'
-generator script. See the [Pump Manual](googletest/docs/PumpManual.md).
-
-### Contributing Code ###
-
-We welcome patches. Please read the
-[Developer's Guide](googletest/docs/DevGuide.md)
-for how you can contribute. In particular, make sure you have signed
-the Contributor License Agreement, or we won't be able to accept the
-patch.
+Please read the [`CONTRIBUTING.md`](CONTRIBUTING.md) for details on
+how to contribute to this project.
Happy testing!
diff --git a/googlemock/README.md b/googlemock/README.md
index f941f158..1170cfab 100644
--- a/googlemock/README.md
+++ b/googlemock/README.md
@@ -337,38 +337,6 @@ use the new matcher API (
[polymorphic](./docs/CookBook.md#writing-new-polymorphic-matchers)).
Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
-### Developing Google Mock ###
-
-This section discusses how to make your own changes to Google Mock.
-
-#### Testing Google Mock 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'll need Autotools. First, make sure you have followed
-the instructions above to configure Google Mock.
-Then, create a build output directory and enter it. Next,
-
- ${GMOCK_DIR}/configure # try --help for more info
-
-Once you have successfully configured Google Mock, the build steps are
-standard for GNU-style OSS packages.
-
- make # Standard makefile following GNU conventions
- make check # Builds and runs all tests - all should pass.
-
-Note that when building your project against Google Mock, you are building
-against Google Test as well. There is no need to configure Google Test
-separately.
-
-#### Contributing a Patch ####
-
-We welcome patches.
-Please read the [Developer's Guide](docs/DevGuide.md)
-for how you can contribute. In particular, make sure you have signed
-the Contributor License Agreement, or we won't be able to accept the
-patch.
-
Happy testing!
[gtest_readme]: ../googletest/README.md "googletest"
diff --git a/googlemock/docs/DevGuide.md b/googlemock/docs/DevGuide.md
deleted file mode 100644
index cae07e70..00000000
--- a/googlemock/docs/DevGuide.md
+++ /dev/null
@@ -1,132 +0,0 @@
-
-
-If you are interested in understanding the internals of Google Mock,
-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 Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
-
-## The Google Mock Community ##
-
-The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the
-[issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control 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
-Mock 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.
-
-### Where to Discuss Google Mock ###
-
-As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock). 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 Mock,
-this is the section for you.
-
-## Checking Out the Source from Subversion ##
-
-Checking out the Google Mock source is most useful if you plan to
-tweak it yourself. You check out the source for Google Mock using a
-[Subversion](http://subversion.tigris.org/) client as you would for any
-other project hosted on Google Code. Please see the instruction on
-the [source code access page](../) for how to do it.
-
-## 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 mocking 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 Mock 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 Mock, 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).
-
-## Submitting Patches ##
-
-Please do submit code. Here's what you need to do:
-
- 1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
- 1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock 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 Mock 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 patch file using `svn diff`.
- 1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews. You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki). When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it. There are several ways to upload the patch. We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
-
-## Google Mock Committers ##
-
-The current members of the Google Mock 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 Mock 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
-Mock.
-
-# Release Process #
-
-We follow the typical release process for Subversion-based projects:
-
- 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/googlemock/docs/Documentation.md b/googlemock/docs/Documentation.md
index a0311871..16083e70 100644
--- a/googlemock/docs/Documentation.md
+++ b/googlemock/docs/Documentation.md
@@ -11,5 +11,5 @@ the respective git branch/tag).**
To contribute code to Google Mock, read:
- * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+ * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
* [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
diff --git a/googletest/README.md b/googletest/README.md
index f273a7de..225aba24 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 88a3de9f..00000000
--- 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 1e4c5c54..3784c8fd 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.