Merge remote-tracking branch 'google/master'

README → README.md

 Google C++ Mocking Framework
 ============================
 
-http://code.google.com/p/googlemock/
+<http://github.com/google/googlemock/>
 
 Overview
 --------
@@ -33,23 +33,22 @@ mailing list for questions, discussions, and development.  There is
 also an IRC channel on OFTC (irc.oftc.net) #gtest available.  Please
 join us!
 
-Please note that code under scripts/generator/ is from the cppclean
-project (http://code.google.com/p/cppclean/) and under the Apache
+Please note that code under scripts/generator/ is from the [cppclean
+project](http://code.google.com/p/cppclean/) and under the Apache
 License, which is different from Google Mock's license.
 
 Requirements for End Users
 --------------------------
 
-Google Mock is implemented on top of the Google Test C++ testing
-framework (http://code.google.com/p/googletest/), and includes the
-latter as part of the SVN repository and distribution package.  You
-must use the bundled version of Google Test when using Google Mock, or
+Google Mock is implemented on top of the [Google Test C++ testing
+framework](http://github.com/google/googletest/), and depends on it.
+You must use the bundled version of Google Test when using Google Mock, or
 you may get compiler/linker errors.
 
 You can also easily configure Google Mock to work with another testing
 framework of your choice; although it will still need Google Test as
 an internal dependency.  Please read
-http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework
+<http://code.google.com/p/googlemock/wiki/ForDummies#Using_Google_Mock_with_Any_Testing_Framework>
 for how to do it.
 
 Google Mock depends on advanced C++ features and thus requires a more
@@ -91,39 +90,19 @@ Getting the Source
 ------------------
 
 There are two primary ways of getting Google Mock's source code: you
-can download a stable source release in your preferred archive format,
-or directly check out the source from our Subversion (SVN) repository.
-The SVN checkout requires a few extra steps and some extra software
+can download a [stable source release](releases),
+or directly check out the source from our Git repository.
+The Git checkout requires a few extra steps and some extra software
 packages on your system, but lets you track development and make
 patches much more easily, so we highly encourage it.
 
-### Source Package ###
+### Git Checkout ###
 
-Google Mock is released in versioned source packages which can be
-downloaded from the download page [1].  Several different archive
-formats are provided, but the only difference is the tools needed to
-extract their contents, and the size of the resulting file.  Download
-whichever you are most comfortable with.
+To check out the master branch of Google Mock, run the following git command:
 
-  [1] http://code.google.com/p/googlemock/downloads/list
+    git clone https://github.com/google/googlemock.git
 
-Once downloaded expand the archive using whichever tools you prefer
-for that type.  This will always result in a new directory with the
-name "gmock-X.Y.Z" which contains all of the source code.  Here are
-some examples on Linux:
-
-  tar -xvzf gmock-X.Y.Z.tar.gz
-  tar -xvjf gmock-X.Y.Z.tar.bz2
-  unzip gmock-X.Y.Z.zip
-
-### SVN Checkout ###
-
-To check out the main branch (also known as the "trunk") of Google
-Mock, run the following Subversion command:
-
-  svn checkout http://googlemock.googlecode.com/svn/trunk/ gmock-svn
-
-If you are using a *nix system and plan to use the GNU Autotools build
+If you are using a \*nix system and plan to use the GNU Autotools build
 system to build Google Mock (described below), you'll need to
 configure it now.  Otherwise you are done with getting the source
 files.
@@ -132,7 +111,7 @@ To prepare the Autotools build system, enter the target directory of
 the checkout command you used ('gmock-svn') and proceed with the
 following command:
 
-  autoreconf -fvi
+    autoreconf -fvi
 
 Once you have completed this step, you are ready to build the library.
 Note that you should only need to complete this step once.  The
@@ -144,7 +123,7 @@ will fail.  You may need to explicitly specify a version to use.  For
 instance, if you have both GNU Automake 1.4 and 1.9 installed and
 'automake' would invoke the 1.4, use instead:
 
-  AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -fvi
+    AUTOMAKE=automake-1.9 ACLOCAL=aclocal-1.9 autoreconf -fvi
 
 Make sure you're using the same version of automake and aclocal.
 
@@ -161,40 +140,40 @@ straightforward.
 This section shows how you can integrate Google Mock into your
 existing build system.
 
-Suppose you put Google Mock in directory ${GMOCK_DIR} and Google Test
-in ${GTEST_DIR} (the latter is ${GMOCK_DIR}/gtest by default).  To
+Suppose you put Google Mock in directory ${GMOCK\_DIR} and Google Test
+in ${GTEST\_DIR} (the latter is ${GMOCK\_DIR}/gtest by default).  To
 build Google Mock, create a library build target (or a project as
 called by Visual Studio and Xcode) to compile
 
-  ${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
+    ${GTEST_DIR}/src/gtest-all.cc and ${GMOCK_DIR}/src/gmock-all.cc
 
 with
 
-  ${GTEST_DIR}/include and ${GMOCK_DIR}/include
+    ${GTEST_DIR}/include and ${GMOCK_DIR}/include
 
 in the system header search path, and
 
-  ${GTEST_DIR} and ${GMOCK_DIR}
+    ${GTEST_DIR} and ${GMOCK_DIR}
 
 in the normal header search path.  Assuming a Linux-like system and gcc,
 something like the following will do:
 
-  g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-      -isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-      -pthread -c ${GTEST_DIR}/src/gtest-all.cc
-  g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
-      -isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
-      -pthread -c ${GMOCK_DIR}/src/gmock-all.cc
-  ar -rv libgmock.a gtest-all.o gmock-all.o
+    g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
+        -isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
+        -pthread -c ${GTEST_DIR}/src/gtest-all.cc
+    g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
+        -isystem ${GMOCK_DIR}/include -I${GMOCK_DIR} \
+        -pthread -c ${GMOCK_DIR}/src/gmock-all.cc
+    ar -rv libgmock.a gtest-all.o gmock-all.o
 
 (We need -pthread as Google Test and Google Mock use threads.)
 
 Next, you should compile your test source file with
-${GTEST_DIR}/include and ${GMOCK_DIR}/include in the header search
+${GTEST\_DIR}/include and ${GMOCK\_DIR}/include in the header search
 path, and link it with gmock and any other necessary libraries:
 
-  g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
-      -pthread path/to/your_test.cc libgmock.a -o your_test
+    g++ -isystem ${GTEST_DIR}/include -isystem ${GMOCK_DIR}/include \
+        -pthread path/to/your_test.cc libgmock.a -o your_test
 
 As an example, the make/ directory contains a Makefile that you can
 use to build Google Mock on systems where GNU make is available
@@ -206,13 +185,11 @@ script.
 If the default settings are correct for your environment, the
 following commands should succeed:
 
-  cd ${GMOCK_DIR}/make
-  make
-  ./gmock_test
+    cd ${GMOCK_DIR}/make
+    make
+    ./gmock_test
 
-If you see errors, try to tweak the contents of make/Makefile to make
-them go away.  There are instructions in make/Makefile on how to do
-it.
+If you see errors, try to tweak the contents of [make/Makefile](make/Makefile) to make them go away.
 
 ### Windows ###
 
@@ -223,11 +200,11 @@ selected tests.
 Change to the appropriate directory and run "msbuild gmock.sln" to
 build the library and tests (or open the gmock.sln in the MSVC IDE).
 If you want to create your own project to use with Google Mock, you'll
-have to configure it to use the gmock_config propety sheet.  For that:
+have to configure it to use the `gmock_config` propety sheet.  For that:
 
  * Open the Property Manager window (View | Other Windows | Property Manager)
  * Right-click on your project and select "Add Existing Property Sheet..."
- * Navigate to gmock_config.vsprops or gmock_config.props and select it.
+ * Navigate to `gmock_config.vsprops` or `gmock_config.props` and select it.
  * In Project Properties | Configuration Properties | General | Additional
    Include Directories, type <path to Google Mock>/include.
 
@@ -238,11 +215,12 @@ Google Mock can be used in diverse environments.  The default
 configuration may not work (or may not work well) out of the box in
 some environments.  However, you can easily tweak Google Mock by
 defining control macros on the compiler command line.  Generally,
-these macros are named like GTEST_XYZ and you define them to either 1
+these macros are named like `GTEST_XYZ` and you define them to either 1
 or 0 to enable or disable a certain feature.
 
 We list the most frequently used macros below.  For a complete list,
-see file ${GTEST_DIR}/include/gtest/internal/gtest-port.h.
+see file [${GTEST\_DIR}/include/gtest/internal/gtest-port.h](
+../googletest/include/gtest/internal/gtest-port.h).
 
 ### Choosing a TR1 Tuple Library ###
 
@@ -259,13 +237,13 @@ you need to tell Google Test and Google Mock to use the same TR1 tuple
 library the rest of your project uses, or the two tuple
 implementations will clash.  To do that, add
 
-  -DGTEST_USE_OWN_TR1_TUPLE=0
+    -DGTEST_USE_OWN_TR1_TUPLE=0
 
 to the compiler flags while compiling Google Test, Google Mock, and
 your tests.  If you want to force Google Test and Google Mock to use
 their own tuple library, just add
 
-  -DGTEST_USE_OWN_TR1_TUPLE=1
+    -DGTEST_USE_OWN_TR1_TUPLE=1
 
 to the compiler flags instead.
 
@@ -277,13 +255,14 @@ it and set it up.
 
 Google Mock is compact, so most users can build and link it as a static
 library for the simplicity.  Google Mock can be used as a DLL, but the
-same DLL must contain Google Test as well.  See Google Test's README
-file for instructions on how to set up necessary compiler settings.
+same DLL must contain Google Test as well.  See
+[Google Test's README][gtest_readme]
+for instructions on how to set up necessary compiler settings.
 
 ### Tweaking Google Mock ###
 
 Most of Google Test's control macros apply to Google Mock as well.
-Please see file ${GTEST_DIR}/README for how to tweak them.
+Please see [Google Test's README][gtest_readme] for how to tweak them.
 
 Upgrading from an Earlier Version
 ---------------------------------
@@ -296,24 +275,24 @@ do if you are upgrading from an earlier version of Google Mock.
 ### Upgrading from 1.1.0 or Earlier ###
 
 You may need to explicitly enable or disable Google Test's own TR1
-tuple library.  See the instructions in section "Choosing a TR1 Tuple
-Library".
+tuple library.  See the instructions in section "[Choosing a TR1 Tuple
+Library](../googletest/#choosing-a-tr1-tuple-library)".
 
 ### Upgrading from 1.4.0 or Earlier ###
 
 On platforms where the pthread library is available, Google Test and
 Google Mock use it in order to be thread-safe.  For this to work, you
 may need to tweak your compiler and/or linker flags.  Please see the
-"Multi-threaded Tests" section in file ${GTEST_DIR}/README for what
-you may need to do.
+"[Multi-threaded Tests](../googletest#multi-threaded-tests
+)" section in file Google Test's README for what you may need to do.
 
-If you have custom matchers defined using MatcherInterface or
-MakePolymorphicMatcher(), you'll need to update their definitions to
-use the new matcher API [2].  Matchers defined using MATCHER() or
-MATCHER_P*() aren't affected.
+If you have custom matchers defined using `MatcherInterface` or
+`MakePolymorphicMatcher()`, you'll need to update their definitions to
+use the new matcher API (
+[monomorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers),
+[polymorphic](http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers)).
+Matchers defined using `MATCHER()` or `MATCHER_P*()` aren't affected.
 
-  [2] http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Monomorphic_Matchers,
-      http://code.google.com/p/googlemock/wiki/CookBook#Writing_New_Polymorphic_Matchers
 
 Developing Google Mock
 ----------------------
@@ -328,13 +307,13 @@ For that you'll need Autotools.  First, make sure you have followed
 the instructions in section "SVN Checkout" to configure Google Mock.
 Then, create a build output directory and enter it.  Next,
 
-  ${GMOCK_DIR}/configure  # Standard GNU configure script, --help for more info
+    ${GMOCK_DIR}/configure  # Standard GNU configure script, --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.
+    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
@@ -345,25 +324,27 @@ separately.
 Some of Google Mock's source files are generated from templates (not
 in the C++ sense) using a script.  A template file is named FOO.pump,
 where FOO is the name of the file it will generate.  For example, the
-file include/gmock/gmock-generated-actions.h.pump is used to generate
-gmock-generated-actions.h in the same directory.
+file `include/gmock/gmock-generated-actions.h.pump` is used to generate
+`gmock-generated-actions.h` in the same directory.
 
 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' script (for Pump
+corresponding `.pump` files instead and run the 'pump' script (for Pump
 is Useful for Meta Programming) to regenerate them.  You can find
-pump.py in the ${GTEST_DIR}/scripts/ directory.  Read the Pump manual
-[3] for how to use it.
+pump.py in the `${GTEST_DIR}/scripts/` directory.  Read the
+[Pump manual](http://code.google.com/p/googletest/wiki/PumpManual)
+for how to use it.
 
-  [3] http://code.google.com/p/googletest/wiki/PumpManual.
 
 ### Contributing a Patch ###
 
-We welcome patches.  Please read the Google Mock developer's guide [4]
+We welcome patches.  Please read the [Google Mock developer's Guide](
+http://code.google.com/p/googlemock/wiki/DevGuide)
 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.
 
-  [4] http://code.google.com/p/googlemock/wiki/DevGuide
 
 Happy testing!
+
+[gtest_readme]: ../googletest/ "googletest"

docs/DesignDoc.md

+This page discusses the design of new Google Mock features.
+
+
+
+# Macros for Defining Actions #
+
+## Problem ##
+
+Due to the lack of closures in C++, it currently requires some
+non-trivial effort to define a custom action in Google Mock.  For
+example, suppose you want to "increment the value pointed to by the
+second argument of the mock function and return it", you could write:
+
+```
+int IncrementArg1(Unused, int* p, Unused) {
+  return ++(*p);
+}
+
+... WillOnce(Invoke(IncrementArg1));
+```
+
+There are several things unsatisfactory about this approach:
+
+  * Even though the action only cares about the second argument of the mock function, its definition needs to list other arguments as dummies.  This is tedious.
+  * The defined action is usable only in mock functions that takes exactly 3 arguments - an unnecessary restriction.
+  * To use the action, one has to say `Invoke(IncrementArg1)`, which isn't as nice as `IncrementArg1()`.
+
+The latter two problems can be overcome using `MakePolymorphicAction()`,
+but it requires much more boilerplate code:
+
+```
+class IncrementArg1Action {
+ public:
+  template <typename Result, typename ArgumentTuple>
+  Result Perform(const ArgumentTuple& args) const {
+    return ++(*tr1::get<1>(args));
+  }
+};
+
+PolymorphicAction<IncrementArg1Action> IncrementArg1() {
+  return MakePolymorphicAction(IncrementArg1Action());
+}
+
+... WillOnce(IncrementArg1());
+```
+
+Our goal is to allow defining custom actions with the least amount of
+boiler-plate C++ requires.
+
+## Solution ##
+
+We propose to introduce a new macro:
+```
+ACTION(name) { statements; }
+```
+
+Using this in a namespace scope will define an action with the given
+name that executes the statements.  Inside the statements, you can
+refer to the K-th (0-based) argument of the mock function as `argK`.
+For example:
+```
+ACTION(IncrementArg1) { return ++(*arg1); }
+```
+allows you to write
+```
+... WillOnce(IncrementArg1());
+```
+
+Note that you don't need to specify the types of the mock function
+arguments, as brevity is a top design goal here.  Rest assured that
+your code is still type-safe though: you'll get a compiler error if
+`*arg1` doesn't support the `++` operator, or if the type of
+`++(*arg1)` isn't compatible with the mock function's return type.
+
+Another example:
+```
+ACTION(Foo) {
+  (*arg2)(5);
+  Blah();
+  *arg1 = 0;
+  return arg0;
+}
+```
+defines an action `Foo()` that invokes argument #2 (a function pointer)
+with 5, calls function `Blah()`, sets the value pointed to by argument
+#1 to 0, and returns argument #0.
+
+For more convenience and flexibility, you can also use the following
+pre-defined symbols in the body of `ACTION`:
+
+| `argK_type` | The type of the K-th (0-based) argument of the mock function |
+|:------------|:-------------------------------------------------------------|
+| `args`      | All arguments of the mock function as a tuple                |
+| `args_type` | The type of all arguments of the mock function as a tuple    |
+| `return_type` | The return type of the mock function                         |
+| `function_type` | The type of the mock function                                |
+
+For example, when using an `ACTION` as a stub action for mock function:
+```
+int DoSomething(bool flag, int* ptr);
+```
+we have:
+| **Pre-defined Symbol** | **Is Bound To** |
+|:-----------------------|:----------------|
+| `arg0`                 | the value of `flag` |
+| `arg0_type`            | the type `bool` |
+| `arg1`                 | the value of `ptr` |
+| `arg1_type`            | the type `int*` |
+| `args`                 | the tuple `(flag, ptr)` |
+| `args_type`            | the type `std::tr1::tuple<bool, int*>` |
+| `return_type`          | the type `int`  |
+| `function_type`        | the type `int(bool, int*)` |
+
+## Parameterized actions ##
+
+Sometimes you'll want to parameterize the action.   For that we propose
+another macro
+```
+ACTION_P(name, param) { statements; }
+```
+
+For example,
+```
+ACTION_P(Add, n) { return arg0 + n; }
+```
+will allow you to write
+```
+// Returns argument #0 + 5.
+... WillOnce(Add(5));
+```
+
+For convenience, we use the term _arguments_ for the values used to
+invoke the mock function, and the term _parameters_ for the values
+used to instantiate an action.
+
+Note that you don't need to provide the type of the parameter either.
+Suppose the parameter is named `param`, you can also use the
+Google-Mock-defined symbol `param_type` to refer to the type of the
+parameter as inferred by the compiler.
+
+We will also provide `ACTION_P2`, `ACTION_P3`, and etc to support
+multi-parameter actions.  For example,
+```
+ACTION_P2(ReturnDistanceTo, x, y) {
+  double dx = arg0 - x;
+  double dy = arg1 - y;
+  return sqrt(dx*dx + dy*dy);
+}
+```
+lets you write
+```
+... WillOnce(ReturnDistanceTo(5.0, 26.5));
+```
+
+You can view `ACTION` as a degenerated parameterized action where the
+number of parameters is 0.
+
+## Advanced Usages ##
+
+### Overloading Actions ###
+
+You can easily define actions overloaded on the number of parameters:
+```
+ACTION_P(Plus, a) { ... }
+ACTION_P2(Plus, a, b) { ... }
+```
+
+### Restricting the Type of an Argument or Parameter ###
+
+For maximum brevity and reusability, the `ACTION*` macros don't let
+you specify the types of the mock function arguments and the action
+parameters.  Instead, we let the compiler infer the types for us.
+
+Sometimes, however, we may want to be more explicit about the types.
+There are several tricks to do that.  For example:
+```
+ACTION(Foo) {
+  // Makes sure arg0 can be converted to int.
+  int n = arg0;
+  ... use n instead of arg0 here ...
+}
+
+ACTION_P(Bar, param) {
+  // Makes sure the type of arg1 is const char*.
+  ::testing::StaticAssertTypeEq<const char*, arg1_type>();
+
+  // Makes sure param can be converted to bool.
+  bool flag = param;
+}
+```
+where `StaticAssertTypeEq` is a compile-time assertion we plan to add to
+Google Test (the name is chosen to match `static_assert` in C++0x).
+
+### Using the ACTION Object's Type ###
+
+If you are writing a function that returns an `ACTION` object, you'll
+need to know its type.  The type depends on the macro used to define
+the action and the parameter types.  The rule is relatively simple:
+| **Given Definition** | **Expression** | **Has Type** |
+|:---------------------|:---------------|:-------------|
+| `ACTION(Foo)`        | `Foo()`        | `FooAction`  |
+| `ACTION_P(Bar, param)` | `Bar(int_value)` | `BarActionP<int>` |
+| `ACTION_P2(Baz, p1, p2)` | `Baz(bool_value, int_value)` | `BazActionP2<bool, int>` |
+| ...                  | ...            | ...          |
+
+Note that we have to pick different suffixes (`Action`, `ActionP`,
+`ActionP2`, and etc) for actions with different numbers of parameters,
+or the action definitions cannot be overloaded on the number of
+parameters.
+
+## When to Use ##
+
+While the new macros are very convenient, please also consider other
+means of implementing actions (e.g. via `ActionInterface` or
+`MakePolymorphicAction()`), especially if you need to use the defined
+action a lot.  While the other approaches require more work, they give
+you more control on the types of the mock function arguments and the
+action parameters, which in general leads to better compiler error
+messages that pay off in the long run.  They also allow overloading
+actions based on parameter types, as opposed to just the number of
+parameters.
+
+## Related Work ##
+
+As you may have realized, the `ACTION*` macros resemble closures (also
+known as lambda expressions or anonymous functions).  Indeed, both of
+them seek to lower the syntactic overhead for defining a function.
+
+C++0x will support lambdas, but they are not part of C++ right now.
+Some non-standard libraries (most notably BLL or Boost Lambda Library)
+try to alleviate this problem.  However, they are not a good choice
+for defining actions as:
+
+  * They are non-standard and not widely installed.  Google Mock only depends on standard libraries and `tr1::tuple`, which is part of the new C++ standard and comes with gcc 4+.  We want to keep it that way.
+  * They are not trivial to learn.
+  * They will become obsolete when C++0x's lambda feature is widely supported.  We don't want to make our users use a dying library.
+  * Since they are based on operators, they are rather ad hoc: you cannot use statements, and you cannot pass the lambda arguments to a function, for example.
+  * They have subtle semantics that easily confuses new users.  For example, in expression `_1++ + foo++`, `foo` will be incremented only once where the expression is evaluated, while `_1` will be incremented every time the unnamed function is invoked.  This is far from intuitive.
+
+`ACTION*` avoid all these problems.
+
+## Future Improvements ##
+
+There may be a need for composing `ACTION*` definitions (i.e. invoking
+another `ACTION` inside the definition of one `ACTION*`).  We are not
+sure we want it yet, as one can get a similar effect by putting
+`ACTION` definitions in function templates and composing the function
+templates.  We'll revisit this based on user feedback.
+
+The reason we don't allow `ACTION*()` inside a function body is that
+the current C++ standard doesn't allow function-local types to be used
+to instantiate templates.  The upcoming C++0x standard will lift this
+restriction.  Once this feature is widely supported by compilers, we
+can revisit the implementation and add support for using `ACTION*()`
+inside a function.
+
+C++0x will also support lambda expressions.  When they become
+available, we may want to support using lambdas as actions.
+
+# Macros for Defining Matchers #
+
+Once the macros for defining actions are implemented, we plan to do
+the same for matchers:
+
+```
+MATCHER(name) { statements; }
+```
+
+where you can refer to the value being matched as `arg`.  For example,
+given:
+
+```
+MATCHER(IsPositive) { return arg > 0; }
+```
+
+you can use `IsPositive()` as a matcher that matches a value iff it is
+greater than 0.
+
+We will also add `MATCHER_P`, `MATCHER_P2`, and etc for parameterized
+matchers.
\ No newline at end of file

docs/DevGuide.md

+
+
+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](http://code.google.com/p/googlemock/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googlemock/source/checkout). 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](http://code.google.com/p/googlemock/source/checkout) 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](http://code.google.com/p/googlemock/source/browse/trunk/README) 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](http://code.google.com/p/googlemock/source/browse/trunk/README) 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](http://code.google.com/p/google-styleguide/) project.  All patches will be expected
+to conform to the style outlined [here](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
+
+## 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](http://code.google.com/p/googlemock/issues/list). 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](http://code.google.com/p/rietveld/wiki/CodeReviewHelp).  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](http://code.google.com/p/googlemock/source/browse/trunk/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/).
\ No newline at end of file

docs/Documentation.md

+This page lists all documentation wiki pages for Google Mock **(the SVN trunk version)**
+- **if you use a released version of Google Mock, please read the documentation for that specific version instead.**
+
+  * [ForDummies](ForDummies.md) -- start here if you are new to Google Mock.
+  * [CheatSheet](CheatSheet.md) -- a quick reference.
+  * [CookBook](CookBook.md) -- recipes for doing various tasks using Google Mock.
+  * [FrequentlyAskedQuestions](FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
+
+To contribute code to Google Mock, read:
+
+  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
\ No newline at end of file

docs/v1_5/Documentation.md

+This page lists all documentation wiki pages for Google Mock **version 1.5.0** -- **if you use a different version of Google Mock, please read the documentation for that specific version instead.**
+
+  * [ForDummies](V1_5_ForDummies.md) -- start here if you are new to Google Mock.
+  * [CheatSheet](V1_5_CheatSheet.md) -- a quick reference.
+  * [CookBook](V1_5_CookBook.md) -- recipes for doing various tasks using Google Mock.
+  * [FrequentlyAskedQuestions](V1_5_FrequentlyAskedQuestions.md) -- check here before asking a question on the mailing list.
+
+To contribute code to Google Mock, read:
+
+  * DevGuide -- read this _before_ writing your first patch.
+  * [Pump Manual](http://code.google.com/p/googletest/wiki/PumpManual) -- how we generate some of Google Mock's source files.
\ No newline at end of file