Merge branch 'wiki' of github.com:BillyDonahue/googletest into wiki

e6ad956e · Billy Donahue · 849f2813 · 642acbd6 · e6ad956e · e6ad956e
Commit e6ad956e authored Aug 22, 2015 by Billy Donahue
20 changed files
--- a/AdvancedGuide.md
+++ b/AdvancedGuide.md
--- a/DevGuide.md
+++ b/DevGuide.md
+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), the
+[issue tracker](http://code.google.com/p/googletest/issues/list) and, to a lesser extent, the [source control repository](http://code.google.com/p/googletest/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
+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.
+### Where to Discuss Google Test ###
+As always, discuss Google Test in the official [Google C++ Testing Framework discussion group](http://groups.google.com/group/googletestframework).  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.
+## Checking Out the Source from Subversion ##
+Checking out the Google Test source is most useful if you plan to
+tweak it yourself.  You check out the source for Google Test 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/googletest/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/googletest/source/browse/trunk/README) 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](http://code.google.com/p/googletest/source/browse/trunk/README) 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](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).
+## 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. 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 Test issue tracker](http://code.google.com/p/googletest/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 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 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 `googletestframework@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gtest.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/upload_gtest.py) script, which you can find in the `scripts/` folder in the SVN trunk.
+## 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 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
--- a/Documentation.md
+++ b/Documentation.md
+This page lists all documentation wiki pages for Google Test **(the SVN trunk version)**
+-- **if you use a released version of Google Test, please read the
+documentation for that specific version instead.**
+  * [Primer](Primer.md) -- start here if you are new to Google Test.
+  * [Samples](Samples.md) -- learn from examples.
+  * [AdvancedGuide](AdvancedGuide.md) -- learn more about Google Test.
+  * [XcodeGuide](XcodeGuide.md) -- how to use Google Test in Xcode on Mac.
+  * [Frequently-Asked Questions](FAQ.md) -- check here before asking a question on the mailing list.
+To contribute code to Google Test, read:
+  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [PumpManual](PumpManual.md) -- how we generate some of Google Test's source files.
\ No newline at end of file
--- a/FAQ.md
+++ b/FAQ.md
--- a/Primer.md
+++ b/Primer.md
--- a/ProjectHome.md
+++ b/ProjectHome.md
+Google's framework for writing C++ tests on a variety of platforms
+(Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian).  Based on
+the xUnit architecture.  Supports automatic test discovery, a rich set
+of assertions, user-defined assertions, death tests, fatal and
+non-fatal failures, value- and type-parameterized tests, various
+options for running the tests, and XML test report generation.
+## Getting Started ##
+After downloading Google Test, unpack it, read the README file and the documentation wiki pages (listed on the right side of this front page).
+## Who Is Using Google Test? ##
+In addition to many internal projects at Google, Google Test is also used by
+the following notable projects:
+  * The [Chromium projects](http://www.chromium.org/) (behind the Chrome browser and Chrome OS)
+  * The [LLVM](http://llvm.org/) compiler
+  * [Protocol Buffers](http://code.google.com/p/protobuf/) (Google's data interchange format)
+  * The [OpenCV](http://opencv.org/) computer vision library
+If you know of a project that's using Google Test and want it to be listed here, please let
+`googletestframework@googlegroups.com` know.
+## Google Test-related open source projects ##
+[Google Test UI](http://code.google.com/p/gtest-gbar/) is test runner that runs your test binary, allows you to track its progress via a progress bar, and displays a list of test failures. Clicking on one shows failure text. Google Test UI is written in C#.
+[GTest TAP Listener](https://github.com/kinow/gtest-tap-listener) is an event listener for Google Test that implements the [TAP protocol](http://en.wikipedia.org/wiki/Test_Anything_Protocol) for test result output. If your test runner understands TAP, you may find it useful.
\ No newline at end of file
--- a/PumpManual.md
+++ b/PumpManual.md
+<b>P</b>ump is <b>U</b>seful for <b>M</b>eta <b>P</b>rogramming.
+# The Problem #
+Template and macro libraries often need to define many classes,
+functions, or macros that vary only (or almost only) in the number of
+arguments they take. It's a lot of repetitive, mechanical, and
+error-prone work.
+Variadic templates and variadic macros can alleviate the problem.
+However, while both are being considered by the C++ committee, neither
+is in the standard yet or widely supported by compilers.  Thus they
+are often not a good choice, especially when your code needs to be
+portable. And their capabilities are still limited.
+As a result, authors of such libraries often have to write scripts to
+generate their implementation. However, our experience is that it's
+tedious to write such scripts, which tend to reflect the structure of
+the generated code poorly and are often hard to read and edit. For
+example, a small change needed in the generated code may require some
+non-intuitive, non-trivial changes in the script. This is especially
+painful when experimenting with the code.
+# Our Solution #
+Pump (for Pump is Useful for Meta Programming, Pretty Useful for Meta
+Programming, or Practical Utility for Meta Programming, whichever you
+prefer) is a simple meta-programming tool for C++. The idea is that a
+programmer writes a `foo.pump` file which contains C++ code plus meta
+code that manipulates the C++ code. The meta code can handle
+iterations over a range, nested iterations, local meta variable
+definitions, simple arithmetic, and conditional expressions. You can
+view it as a small Domain-Specific Language. The meta language is
+designed to be non-intrusive (s.t. it won't confuse Emacs' C++ mode,
+for example) and concise, making Pump code intuitive and easy to
+maintain.
+## Highlights ##
+  * The implementation is in a single Python script and thus ultra portable: no build or installation is needed and it works cross platforms.
+  * Pump tries to be smart with respect to [Google's style guide](http://code.google.com/p/google-styleguide/): it breaks long lines (easy to have when they are generated) at acceptable places to fit within 80 columns and indent the continuation lines correctly.
+  * The format is human-readable and more concise than XML.
+  * The format works relatively well with Emacs' C++ mode.
+## Examples ##
+The following Pump code (where meta keywords start with `$`, `[[` and `]]` are meta brackets, and `$$` starts a meta comment that ends with the line):
+```
+$var n = 3     $$ Defines a meta variable n.
+$range i 0..n  $$ Declares the range of meta iterator i (inclusive).
+$for i [[
+               $$ Meta loop.
+// Foo$i does blah for $i-ary predicates.
+$range j 1..i
+template <size_t N $for j [[, typename A$j]]>
+class Foo$i {
+$if i == 0 [[
+  blah a;
+]] $elif i <= 2 [[
+  blah b;
+]] $else [[
+  blah c;
+]]
+};
+]]
+```
+will be translated by the Pump compiler to:
+```
+// Foo0 does blah for 0-ary predicates.
+template <size_t N>
+class Foo0 {
+  blah a;
+};
+// Foo1 does blah for 1-ary predicates.
+template <size_t N, typename A1>
+class Foo1 {
+  blah b;
+};
+// Foo2 does blah for 2-ary predicates.
+template <size_t N, typename A1, typename A2>
+class Foo2 {
+  blah b;
+};
+// Foo3 does blah for 3-ary predicates.
+template <size_t N, typename A1, typename A2, typename A3>
+class Foo3 {
+  blah c;
+};
+```
+In another example,
+```
+$range i 1..n
+Func($for i + [[a$i]]);
+$$ The text between i and [[ is the separator between iterations.
+```
+will generate one of the following lines (without the comments), depending on the value of `n`:
+```
+Func();              // If n is 0.
+Func(a1);            // If n is 1.
+Func(a1 + a2);       // If n is 2.
+Func(a1 + a2 + a3);  // If n is 3.
+// And so on...
+```
+## Constructs ##
+We support the following meta programming constructs:
+| `$var id = exp` | Defines a named constant value. `$id` is valid util the end of the current meta lexical block. |
+|:----------------|:-----------------------------------------------------------------------------------------------|
+| `$range id exp..exp` | Sets the range of an iteration variable, which can be reused in multiple loops later.          |
+| `$for id sep [[ code ]]` | Iteration. The range of `id` must have been defined earlier. `$id` is valid in `code`.         |
+| `$($)`          | Generates a single `$` character.                                                              |
+| `$id`           | Value of the named constant or iteration variable.                                             |
+| `$(exp)`        | Value of the expression.                                                                       |
+| `$if exp [[ code ]] else_branch` | Conditional.                                                                                   |
+| `[[ code ]]`    | Meta lexical block.                                                                            |
+| `cpp_code`      | Raw C++ code.                                                                                  |
+| `$$ comment`    | Meta comment.                                                                                  |
+**Note:** To give the user some freedom in formatting the Pump source
+code, Pump ignores a new-line character if it's right after `$for foo`
+or next to `[[` or `]]`. Without this rule you'll often be forced to write
+very long lines to get the desired output. Therefore sometimes you may
+need to insert an extra new-line in such places for a new-line to show
+up in your output.
+## Grammar ##
+```
+code ::= atomic_code*
+atomic_code ::= $var id = exp
+    | $var id = [[ code ]]
+    | $range id exp..exp
+    | $for id sep [[ code ]]
+    | $($)
+    | $id
+    | $(exp)
+    | $if exp [[ code ]] else_branch
+    | [[ code ]]
+    | cpp_code
+sep ::= cpp_code | empty_string
+else_branch ::= $else [[ code ]]
+    | $elif exp [[ code ]] else_branch
+    | empty_string
+exp ::= simple_expression_in_Python_syntax
+```
+## Code ##
+You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
+very unpolished and lacks automated tests, although it has been
+successfully used many times. If you find a chance to use it in your
+project, please let us know what you think!  We also welcome help on
+improving Pump.
+## Real Examples ##
+You can find real-world applications of Pump in [Google Test](http://www.google.com/codesearch?q=file%3A\.pump%24+package%3Ahttp%3A%2F%2Fgoogletest\.googlecode\.com) and [Google Mock](http://www.google.com/codesearch?q=file%3A\.pump%24+package%3Ahttp%3A%2F%2Fgooglemock\.googlecode\.com).  The source file `foo.h.pump` generates `foo.h`.
+## Tips ##
+  * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
+  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
\ No newline at end of file
--- a/Samples.md
+++ b/Samples.md
+If you're like us, you'd like to look at some Google Test sample code.  The
+[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
+variety of Google Test features.
+  * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
+  * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
+  * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
+  * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
+  * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
+  * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
+  * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
+  * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
+  * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
+  * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
\ No newline at end of file
--- a/V1_5_AdvancedGuide.md
+++ b/V1_5_AdvancedGuide.md
--- a/V1_5_Documentation.md
+++ b/V1_5_Documentation.md
+This page lists all official documentation wiki pages for Google Test **1.5.0** -- **if you use a different version of Google Test, make sure to read the documentation for that version instead.**
+  * [Primer](V1_5_Primer.md) -- start here if you are new to Google Test.
+  * [Samples](Samples.md) -- learn from examples.
+  * [AdvancedGuide](V1_5_AdvancedGuide.md) -- learn more about Google Test.
+  * [XcodeGuide](V1_5_XcodeGuide.md) -- how to use Google Test in Xcode on Mac.
+  * [Frequently-Asked Questions](V1_5_FAQ.md) -- check here before asking a question on the mailing list.
+To contribute code to Google Test, read:
+  * DevGuide -- read this _before_ writing your first patch.
+  * [PumpManual](V1_5_PumpManual.md) -- how we generate some of Google Test's source files.
\ No newline at end of file
--- a/V1_5_FAQ.md
+++ b/V1_5_FAQ.md
--- a/V1_5_Primer.md
+++ b/V1_5_Primer.md
--- a/V1_5_PumpManual.md
+++ b/V1_5_PumpManual.md
+<b>P</b>ump is <b>U</b>seful for <b>M</b>eta <b>P</b>rogramming.
+# The Problem #
+Template and macro libraries often need to define many classes,
+functions, or macros that vary only (or almost only) in the number of
+arguments they take. It's a lot of repetitive, mechanical, and
+error-prone work.
+Variadic templates and variadic macros can alleviate the problem.
+However, while both are being considered by the C++ committee, neither
+is in the standard yet or widely supported by compilers.  Thus they
+are often not a good choice, especially when your code needs to be
+portable. And their capabilities are still limited.
+As a result, authors of such libraries often have to write scripts to
+generate their implementation. However, our experience is that it's
+tedious to write such scripts, which tend to reflect the structure of
+the generated code poorly and are often hard to read and edit. For
+example, a small change needed in the generated code may require some
+non-intuitive, non-trivial changes in the script. This is especially
+painful when experimenting with the code.
+# Our Solution #
+Pump (for Pump is Useful for Meta Programming, Pretty Useful for Meta
+Programming, or Practical Utility for Meta Programming, whichever you
+prefer) is a simple meta-programming tool for C++. The idea is that a
+programmer writes a `foo.pump` file which contains C++ code plus meta
+code that manipulates the C++ code. The meta code can handle
+iterations over a range, nested iterations, local meta variable
+definitions, simple arithmetic, and conditional expressions. You can
+view it as a small Domain-Specific Language. The meta language is
+designed to be non-intrusive (s.t. it won't confuse Emacs' C++ mode,
+for example) and concise, making Pump code intuitive and easy to
+maintain.
+## Highlights ##
+  * The implementation is in a single Python script and thus ultra portable: no build or installation is needed and it works cross platforms.
+  * Pump tries to be smart with respect to [Google's style guide](http://code.google.com/p/google-styleguide/): it breaks long lines (easy to have when they are generated) at acceptable places to fit within 80 columns and indent the continuation lines correctly.
+  * The format is human-readable and more concise than XML.
+  * The format works relatively well with Emacs' C++ mode.
+## Examples ##
+The following Pump code (where meta keywords start with `$`, `[[` and `]]` are meta brackets, and `$$` starts a meta comment that ends with the line):
+```
+$var n = 3     $$ Defines a meta variable n.
+$range i 0..n  $$ Declares the range of meta iterator i (inclusive).
+$for i [[
+               $$ Meta loop.
+// Foo$i does blah for $i-ary predicates.
+$range j 1..i
+template <size_t N $for j [[, typename A$j]]>
+class Foo$i {
+$if i == 0 [[
+  blah a;
+]] $elif i <= 2 [[
+  blah b;
+]] $else [[
+  blah c;
+]]
+};
+]]
+```
+will be translated by the Pump compiler to:
+```
+// Foo0 does blah for 0-ary predicates.
+template <size_t N>
+class Foo0 {
+  blah a;
+};
+// Foo1 does blah for 1-ary predicates.
+template <size_t N, typename A1>
+class Foo1 {
+  blah b;
+};
+// Foo2 does blah for 2-ary predicates.
+template <size_t N, typename A1, typename A2>
+class Foo2 {
+  blah b;
+};
+// Foo3 does blah for 3-ary predicates.
+template <size_t N, typename A1, typename A2, typename A3>
+class Foo3 {
+  blah c;
+};
+```
+In another example,
+```
+$range i 1..n
+Func($for i + [[a$i]]);
+$$ The text between i and [[ is the separator between iterations.
+```
+will generate one of the following lines (without the comments), depending on the value of `n`:
+```
+Func();              // If n is 0.
+Func(a1);            // If n is 1.
+Func(a1 + a2);       // If n is 2.
+Func(a1 + a2 + a3);  // If n is 3.
+// And so on...
+```
+## Constructs ##
+We support the following meta programming constructs:
+| `$var id = exp` | Defines a named constant value. `$id` is valid util the end of the current meta lexical block. |
+|:----------------|:-----------------------------------------------------------------------------------------------|
+| $range id exp..exp | Sets the range of an iteration variable, which can be reused in multiple loops later.          |
+| $for id sep [[code ](.md)] | Iteration. The range of `id` must have been defined earlier. `$id` is valid in `code`.         |
+| `$($)`          | Generates a single `$` character.                                                              |
+| `$id`           | Value of the named constant or iteration variable.                                             |
+| `$(exp)`        | Value of the expression.                                                                       |
+| `$if exp [[ code ]] else_branch` | Conditional.                                                                                   |
+| `[[ code ]]`    | Meta lexical block.                                                                            |
+| `cpp_code`      | Raw C++ code.                                                                                  |
+| `$$ comment`    | Meta comment.                                                                                  |
+**Note:** To give the user some freedom in formatting the Pump source
+code, Pump ignores a new-line character if it's right after `$for foo`
+or next to `[[` or `]]`. Without this rule you'll often be forced to write
+very long lines to get the desired output. Therefore sometimes you may
+need to insert an extra new-line in such places for a new-line to show
+up in your output.
+## Grammar ##
+```
+code ::= atomic_code*
+atomic_code ::= $var id = exp
+    | $var id = [[ code ]]
+    | $range id exp..exp
+    | $for id sep [[ code ]]
+    | $($)
+    | $id
+    | $(exp)
+    | $if exp [[ code ]] else_branch
+    | [[ code ]]
+    | cpp_code
+sep ::= cpp_code | empty_string
+else_branch ::= $else [[ code ]]
+    | $elif exp [[ code ]] else_branch
+    | empty_string
+exp ::= simple_expression_in_Python_syntax
+```
+## Code ##
+You can find the source code of Pump in [scripts/pump.py](http://code.google.com/p/googletest/source/browse/trunk/scripts/pump.py). It is still
+very unpolished and lacks automated tests, although it has been
+successfully used many times. If you find a chance to use it in your
+project, please let us know what you think!  We also welcome help on
+improving Pump.
+## Real Examples ##
+You can find real-world applications of Pump in [Google Test](http://www.google.com/codesearch?q=file%3A\.pump%24+package%3Ahttp%3A%2F%2Fgoogletest\.googlecode\.com) and [Google Mock](http://www.google.com/codesearch?q=file%3A\.pump%24+package%3Ahttp%3A%2F%2Fgooglemock\.googlecode\.com).  The source file `foo.h.pump` generates `foo.h`.
+## Tips ##
+  * If a meta variable is followed by a letter or digit, you can separate them using `[[]]`, which inserts an empty string. For example `Foo$j[[]]Helper` generate `Foo1Helper` when `j` is 1.
+  * To avoid extra-long Pump source lines, you can break a line anywhere you want by inserting `[[]]` followed by a new line. Since any new-line character next to `[[` or `]]` is ignored, the generated code won't contain this new line.
\ No newline at end of file
--- a/V1_5_XcodeGuide.md
+++ b/V1_5_XcodeGuide.md
+This guide will explain how to use the Google Testing Framework in your Xcode projects on Mac OS X. This tutorial begins by quickly explaining what to do for experienced users. After the quick start, the guide goes provides additional explanation about each step.
+# Quick Start #
+Here is the quick guide for using Google Test in your Xcode project.
+  1. Download the source from the [website](http://code.google.com/p/googletest) using this command: `svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only`
+  1. Open up the `gtest.xcodeproj` in the `googletest-read-only/xcode/` directory and build the gtest.framework.
+  1. Create a new "Shell Tool" target in your Xcode project called something like "UnitTests"
+  1. Add the gtest.framework to your project and add it to the "Link Binary with Libraries" build phase of "UnitTests"
+  1. Add your unit test source code to the "Compile Sources" build phase of "UnitTests"
+  1. Edit the "UnitTests" executable and add an environment variable named "DYLD\_FRAMEWORK\_PATH" with a value equal to the path to the framework containing the gtest.framework relative to the compiled executable.
+  1. Build and Go
+The following sections further explain each of the steps listed above in depth, describing in more detail how to complete it including some variations.
+# Get the Source #
+Currently, the gtest.framework discussed here isn't available in a tagged release of Google Test, it is only available in the trunk. As explained at the Google Test [site](http://code.google.com/p/googletest/source/checkout">svn), you can get the code from anonymous SVN with this command:
+```
+svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only
+```
+Alternatively, if you are working with Subversion in your own code base, you can add Google Test as an external dependency to your own Subversion repository. By following this approach, everyone that checks out your svn repository will also receive a copy of Google Test (a specific version, if you wish) without having to check it out explicitly. This makes the set up of your project simpler and reduces the copied code in the repository.
+To use `svn:externals`, decide where you would like to have the external source reside. You might choose to put the external source inside the trunk, because you want it to be part of the branch when you make a release. However, keeping it outside the trunk in a version-tagged directory called something like `third-party/googletest/1.0.1`, is another option. Once the location is established, use `svn propedit svn:externals _directory_` to set the svn:externals property on a directory in your repository. This directory won't contain the code, but be its versioned parent directory.
+The command `svn propedit` will bring up your Subversion editor, making editing the long, (potentially multi-line) property simpler. This same method can be used to check out a tagged branch, by using the appropriate URL (e.g. `http://googletest.googlecode.com/svn/tags/release-1.0.1`). Additionally, the svn:externals property allows the specification of a particular revision of the trunk with the `-r_##_` option (e.g. `externals/src/googletest -r60 http://googletest.googlecode.com/svn/trunk`).
+Here is an example of using the svn:externals properties on a trunk (read via `svn propget`) of a project. This value checks out a copy of Google Test into the `trunk/externals/src/googletest/` directory.
+```
+[Computer:svn] user$ svn propget svn:externals trunk
+externals/src/googletest http://googletest.googlecode.com/svn/trunk
+```
+# Add the Framework to Your Project #
+The next step is to build and add the gtest.framework to your own project. This guide describes two common ways below.
+  * **Option 1** --- The simplest way to add Google Test to your own project, is to open gtest.xcodeproj (found in the xcode/ directory of the Google Test trunk) and build the framework manually. Then, add the built framework into your project using the "Add->Existing Framework..." from the context menu or "Project->Add..." from the main menu. The gtest.framework is relocatable and contains the headers and object code that you'll need to make tests. This method requires rebuilding every time you upgrade Google Test in your project.
+  * **Option 2** --- If you are going to be living off the trunk of Google Test, incorporating its latest features into your unit tests (or are a Google Test developer yourself). You'll want to rebuild the framework every time the source updates. to do this, you'll need to add the gtest.xcodeproj file, not the framework itself, to your own Xcode project. Then, from the build products that are revealed by the project's disclosure triangle, you can find the gtest.framework, which can be added to your targets (discussed below).
+# Make a Test Target #
+To start writing tests, make a new "Shell Tool" target. This target template is available under BSD, Cocoa, or Carbon. Add your unit test source code to the "Compile Sources" build phase of the target.
+Next, you'll want to add gtest.framework in two different ways, depending upon which option you chose above.
+  * **Option 1** --- During compilation, Xcode will need to know that you are linking against the gtest.framework. Add the gtest.framework to the "Link Binary with Libraries" build phase of your test target. This will include the Google Test headers in your header search path, and will tell the linker where to find the library.
+  * **Option 2** --- If your working out of the trunk, you'll also want to add gtest.framework to your "Link Binary with Libraries" build phase of your test target. In addition, you'll  want to add the gtest.framework as a dependency to your unit test target. This way, Xcode will make sure that gtest.framework is up to date, every time your build your target. Finally, if you don't share build directories with Google Test, you'll have to copy the gtest.framework into your own build products directory using a "Run Script" build phase.
+# Set Up the Executable Run Environment #
+Since the unit test executable is a shell tool, it doesn't have a bundle with a `Contents/Frameworks` directory, in which to place gtest.framework. Instead, the dynamic linker must be told at runtime to search for the framework in another location. This can be accomplished by setting the "DYLD\_FRAMEWORK\_PATH" environment variable in the "Edit Active Executable ..." Arguments tab, under "Variables to be set in the environment:". The path for this value is the path (relative or absolute) of the directory containing the gtest.framework.
+If you haven't set up the DYLD\_FRAMEWORK\_PATH, correctly, you might get a message like this:
+```
+[Session started at 2008-08-15 06:23:57 -0600.]
+  dyld: Library not loaded: @loader_path/../Frameworks/gtest.framework/Versions/A/gtest
+    Referenced from: /Users/username/Documents/Sandbox/gtestSample/build/Debug/WidgetFrameworkTest
+    Reason: image not found
+```
+To correct this problem, got to the directory containing the executable named in "Referenced from:" value in the error message above. Then, with the terminal in this location, find the relative path to the directory containing the gtest.framework. That is the value you'll need to set as the DYLD\_FRAMEWORK\_PATH.
+# Build and Go #
+Now, when you click "Build and Go", the test will be executed. Dumping out something like this:
+```
+[Session started at 2008-08-06 06:36:13 -0600.]
+[==========] Running 2 tests from 1 test case.
+[----------] Global test environment set-up.
+[----------] 2 tests from WidgetInitializerTest
+[ RUN      ] WidgetInitializerTest.TestConstructor
+[       OK ] WidgetInitializerTest.TestConstructor
+[ RUN      ] WidgetInitializerTest.TestConversion
+[       OK ] WidgetInitializerTest.TestConversion
+[----------] Global test environment tear-down
+[==========] 2 tests from 1 test case ran.
+[  PASSED  ] 2 tests.
+The Debugger has exited with status 0.  
+```
+# Summary #
+Unit testing is a valuable way to ensure your data model stays valid even during rapid development or refactoring. The Google Testing Framework is a great unit testing framework for C and C++ which integrates well with an Xcode development environment.
\ No newline at end of file
--- a/V1_6_AdvancedGuide.md
+++ b/V1_6_AdvancedGuide.md
--- a/V1_6_Documentation.md
+++ b/V1_6_Documentation.md
+This page lists all documentation wiki pages for Google Test **1.6**
+-- **if you use a released version of Google Test, please read the
+documentation for that specific version instead.**
+  * [Primer](V1_6_Primer.md) -- start here if you are new to Google Test.
+  * [Samples](V1_6_Samples.md) -- learn from examples.
+  * [AdvancedGuide](V1_6_AdvancedGuide.md) -- learn more about Google Test.
+  * [XcodeGuide](V1_6_XcodeGuide.md) -- how to use Google Test in Xcode on Mac.
+  * [Frequently-Asked Questions](V1_6_FAQ.md) -- check here before asking a question on the mailing list.
+To contribute code to Google Test, read:
+  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [PumpManual](V1_6_PumpManual.md) -- how we generate some of Google Test's source files.
\ No newline at end of file
--- a/V1_6_FAQ.md
+++ b/V1_6_FAQ.md
--- a/V1_6_Primer.md
+++ b/V1_6_Primer.md
--- a/V1_6_PumpManual.md
+++ b/V1_6_PumpManual.md
--- a/V1_6_Samples.md
+++ b/V1_6_Samples.md
+If you're like us, you'd like to look at some Google Test sample code.  The
+[samples folder](http://code.google.com/p/googletest/source/browse/#svn/trunk/samples) has a number of well-commented samples showing how to use a
+variety of Google Test features.
+  * [Sample #1](http://code.google.com/p/googletest/source/browse/trunk/samples/sample1_unittest.cc) shows the basic steps of using Google Test to test C++ functions.
+  * [Sample #2](http://code.google.com/p/googletest/source/browse/trunk/samples/sample2_unittest.cc) shows a more complex unit test for a class with multiple member functions.
+  * [Sample #3](http://code.google.com/p/googletest/source/browse/trunk/samples/sample3_unittest.cc) uses a test fixture.
+  * [Sample #4](http://code.google.com/p/googletest/source/browse/trunk/samples/sample4_unittest.cc) is another basic example of using Google Test.
+  * [Sample #5](http://code.google.com/p/googletest/source/browse/trunk/samples/sample5_unittest.cc) teaches how to reuse a test fixture in multiple test cases by deriving sub-fixtures from it.
+  * [Sample #6](http://code.google.com/p/googletest/source/browse/trunk/samples/sample6_unittest.cc) demonstrates type-parameterized tests.
+  * [Sample #7](http://code.google.com/p/googletest/source/browse/trunk/samples/sample7_unittest.cc) teaches the basics of value-parameterized tests.
+  * [Sample #8](http://code.google.com/p/googletest/source/browse/trunk/samples/sample8_unittest.cc) shows using `Combine()` in value-parameterized tests.
+  * [Sample #9](http://code.google.com/p/googletest/source/browse/trunk/samples/sample9_unittest.cc) shows use of the listener API to modify Google Test's console output and the use of its reflection API to inspect test results.
+  * [Sample #10](http://code.google.com/p/googletest/source/browse/trunk/samples/sample10_unittest.cc) shows use of the listener API to implement a primitive memory leak checker.
\ No newline at end of file