jaclang 0.6.1__py3-none-any.whl → 0.6.2__py3-none-any.whl

jaclang/vendor/mypyc/doc/using_type_annotations.rst

@@ -0,0 +1,398 @@
+.. _using-type-annotations:
+
+Using type annotations
+======================
+
+You will get the most out of mypyc if you compile code with precise
+type annotations. Not all type annotations will help performance
+equally, however. Using types such as :ref:`primitive types
+<primitive-types>`, :ref:`native classes <native-class-intro>`,
+:ref:`union types <union-types>`, :ref:`trait types <trait-types>`,
+and :ref:`tuple types <tuple-types>` as much as possible is a key to
+major performance gains over CPython.
+
+In contrast, some other types, including ``Any``, are treated as
+:ref:`erased types <erased-types>`.  Operations on erased types use
+generic operations that work with arbitrary objects, similar to how
+the CPython interpreter works. If you only use erased types, the only
+notable benefits over CPython will be the removal of interpreter
+overhead (from compilation) and a bit of :ref:`early binding
+<early-binding>`, which will usually only give minor performance
+gains.
+
+.. _primitive-types:
+
+Primitive types
+---------------
+
+The following built-in types are treated as *primitive types* by
+mypyc, and many operations on these types have efficient
+implementations:
+
+* ``int`` (:ref:`native operations <int-ops>`)
+* ``i64`` (:ref:`documentation <native-ints>`, :ref:`native operations <int-ops>`)
+* ``i32`` (:ref:`documentation <native-ints>`, :ref:`native operations <int-ops>`)
+* ``i16`` (:ref:`documentation <native-ints>`, :ref:`native operations <int-ops>`)
+* ``u8`` (:ref:`documentation <native-ints>`, :ref:`native operations <int-ops>`)
+* ``float`` (:ref:`native operations <float-ops>`)
+* ``bool`` (:ref:`native operations <bool-ops>`)
+* ``str`` (:ref:`native operations <str-ops>`)
+* ``List[T]`` (:ref:`native operations <list-ops>`)
+* ``Dict[K, V]`` (:ref:`native operations <dict-ops>`)
+* ``Set[T]`` (:ref:`native operations <set-ops>`)
+* ``Tuple[T, ...]`` (variable-length tuple; :ref:`native operations <tuple-ops>`)
+* ``None``
+
+The link after each type lists all supported native, optimized
+operations for the type. You can use all operations supported by
+Python, but *native operations* will have custom, optimized
+implementations.
+
+Primitive containers
+--------------------
+
+Primitive container objects such as ``list`` and ``dict`` don't
+maintain knowledge of the item types at runtime -- the item type is
+*erased*.
+
+This means that item types are checked when items are accessed, not
+when a container is passed as an argument or assigned to another
+variable. For example, here we have a runtime type error on the final
+line of ``example`` (the ``Any`` type means an arbitrary, unchecked
+value)::
+
+    from typing import List, Any
+
+    def example(a: List[Any]) -> None:
+        b: List[int] = a  # No error -- items are not checked
+        print(b[0])  # Error here -- got str, but expected int
+
+    example(["x"])
+
+.. _native-class-intro:
+
+Native classes
+--------------
+
+Classes that get compiled to C extensions are called native
+classes. Most common operations on instances of these classes are
+optimized, including construction, attribute access and method calls.
+
+Native class definitions look exactly like normal Python class
+definitions.  A class is usually native if it's in a compiled module
+(though there are some exceptions).
+
+Consider this example:
+
+.. code-block::
+
+   class Point:
+       def __init__(self, x: int, y: int) -> None:
+           self.x = x
+           self.y = y
+
+   def shift(p: Point) -> Point:
+       return Point(p.x + 1, p.y + 1)
+
+All operations in the above example use native operations, if the file
+is compiled.
+
+Native classes have some notable different from Python classes:
+
+* Only attributes and methods defined in the class body or methods are
+  supported.  If you try to assign to an undefined attribute outside
+  the class definition, ``AttributeError`` will be raised. This enables
+  an efficient memory layout and fast method calls for native classes.
+
+* Native classes usually don't define the ``__dict__`` attribute (they
+  don't have an attribute dictionary). This follows from only having
+  a specific set of attributes.
+
+* Native classes can't have an arbitrary metaclass or use most class
+  decorators.
+
+Native classes only support single inheritance. A limited form of
+multiple inheritance is supported through *trait types*. You generally
+must inherit from another native class (or ``object``). By default,
+you can't inherit a Python class from a native class (but there's
+an :ref:`override <inheritance>` to allow that).
+
+See :ref:`native-classes` for more details.
+
+.. _tuple-types:
+
+Tuple types
+-----------
+
+Fixed-length
+`tuple types <https://mypy.readthedocs.io/en/stable/kinds_of_types.html#tuple-types>`_
+such as ``Tuple[int, str]`` are represented
+as :ref:`value types <value-and-heap-types>` when stored in variables,
+passed as arguments, or returned from functions. Value types are
+allocated in the low-level machine stack or in CPU registers, as
+opposed to *heap types*, which are allocated dynamically from the
+heap.
+
+Like all value types, tuples will be *boxed*, i.e. converted to
+corresponding heap types, when stored in Python containers, or passed
+to non-native code. A boxed tuple value will be a regular Python tuple
+object.
+
+.. _union-types:
+
+Union types
+-----------
+
+`Union types <https://mypy.readthedocs.io/en/stable/kinds_of_types.html#union-types>`_
+and
+`optional types <https://mypy.readthedocs.io/en/stable/kinds_of_types.html#optional-types-and-the-none-type>`_
+that contain primitive types, native class types and
+trait types are also efficient. If a union type has
+:ref:`erased <erased-types>` items, accessing items with
+non-erased types is often still quite efficient.
+
+A value with a union types is always :ref:`boxed <value-and-heap-types>`,
+even if it contains a value that also has an unboxed representation, such
+as an integer or a boolean.
+
+For example, using ``Optional[int]`` is quite efficient, but the value
+will always be boxed. A plain ``int`` value will usually be faster, since
+it has an unboxed representation.
+
+.. _trait-types:
+
+Trait types
+-----------
+
+Trait types enable a form of multiple inheritance for native classes.
+A native class can inherit any number of traits.  Trait types are
+defined as classes using the ``mypy_extensions.trait`` decorator::
+
+    from mypy_extensions import trait
+
+    @trait
+    class MyTrait:
+        def method(self) -> None:
+            ...
+
+Traits can define methods, properties and attributes. They often
+define abstract methods. Traits can be generic.
+
+If a class subclasses both a non-trait class and traits, the traits
+must be placed at the end of the base class list::
+
+    class Base: ...
+
+    class Derived(Base, MyTrait, FooTrait):  # OK
+        ...
+
+    class Derived2(MyTrait, FooTrait, Base):
+        # Error: traits should come last
+        ...
+
+Traits have some special properties:
+
+* You shouldn't create instances of traits (though mypyc does not
+  prevent it yet).
+
+* Traits can subclass other traits or native classes, but the MRO must be
+  linear (just like with native classes).
+
+* Accessing methods or attributes through a trait type is somewhat
+  less efficient than through a native class type, but this is much
+  faster than through Python class types or other
+  :ref:`erased types <erased-types>`.
+
+You need to install ``mypy-extensions`` to use ``@trait``:
+
+.. code-block:: text
+
+    pip install --upgrade mypy-extensions
+
+.. _erased-types:
+
+Erased types
+------------
+
+Mypyc supports many other kinds of types as well, beyond those
+described above.  However, these types don't have customized
+operations, and they are implemented using *type erasure*.  Type
+erasure means that all other types are equivalent to untyped values at
+runtime, i.e. they are the equivalent of the type ``Any``. Erased
+types include these:
+
+* Python classes (including ABCs)
+
+* Non-mypyc extension types and primitive types (including built-in
+  types that are not primitives)
+
+* `Callable types <https://mypy.readthedocs.io/en/stable/kinds_of_types.html#callable-types-and-lambdas>`_
+
+* `Type variable types <https://mypy.readthedocs.io/en/stable/generics.html>`_
+
+* Type `Any <https://mypy.readthedocs.io/en/stable/dynamic_typing.html>`_
+
+* Protocol types
+
+Using erased types can still improve performance, since they can
+enable better types to be inferred for expressions that use these
+types.  For example, a value with type ``Callable[[], int]`` will not
+allow native calls. However, the return type is a primitive type, and
+we can use fast operations on the return value::
+
+    from typing import Callable
+
+    def call_and_inc(f: Callable[[], int]) -> int:
+        # Slow call, since f has an erased type
+        n = f()
+        # Fast increment; inferred type of n is int (primitive type)
+        n += 1
+        return n
+
+If the type of the argument ``f`` was ``Any``, the type of ``n`` would
+also be ``Any``, resulting in a generic, slower increment operation
+being used.
+
+Strict runtime type checking
+----------------------------
+
+Compiled code ensures that any variable or expression with a
+non-erased type only has compatible values at runtime. This is in
+contrast with using *optional static typing*, such as by using mypy,
+when type annotations are not enforced at runtime. Mypyc ensures
+type safety both statically and at runtime.
+
+``Any`` types and erased types in general can compromise type safety,
+and this is by design. Inserting strict runtime type checks for all
+possible values would be too expensive and against the goal of
+high performance.
+
+.. _value-and-heap-types:
+
+Value and heap types
+--------------------
+
+In CPython, memory for all objects is dynamically allocated on the
+heap. All Python types are thus *heap types*. In compiled code, some
+types are *value types* -- no object is (necessarily) allocated on the
+heap.  ``bool``, ``float``, ``None``, :ref:`native integer types <native-ints>`
+and fixed-length tuples are value types.
+
+``int`` is a hybrid. For typical integer values, it is a value
+type. Large enough integer values, those that require more than 63
+bits (or 31 bits on 32-bit platforms) to represent, use a heap-based
+representation (same as CPython).
+
+Value types have a few differences from heap types:
+
+* When an instance of a value type is used in a context that expects a
+  heap value, for example as a list item, it will transparently switch
+  to a heap-based representation (boxing) as needed.
+
+* Similarly, mypyc transparently changes from a heap-based
+  representation to a value representation (unboxing).
+
+* Object identity of integers, floating point values and tuples is not
+  preserved. You should use ``==`` instead of ``is`` if you are comparing
+  two integers, floats or fixed-length tuples.
+
+* When an instance of a subclass of a value type is converted to the
+  base type, it is implicitly converted to an instance of the target
+  type.  For example, a ``bool`` value assigned to a variable with an
+  ``int`` type will be converted to the corresponding integer.
+
+The latter conversion is the only implicit type conversion that
+happens in mypyc programs.
+
+Example::
+
+    def example() -> None:
+        # A small integer uses the value (unboxed) representation
+        x = 5
+        # A large integer uses the heap (boxed) representation
+        x = 2**500
+        # Lists always contain boxed integers
+        a = [55]
+        # When reading from a list, the object is automatically unboxed
+        x = a[0]
+        # True is converted to 1 on assignment
+        x = True
+
+Since integers and floating point values have a different runtime
+representations and neither can represent all the values of the other
+type, type narrowing of floating point values through assignment is
+disallowed in compiled code. For consistency, mypyc rejects assigning
+an integer value to a float variable even in variable initialization.
+An explicit conversion is required.
+
+Examples::
+
+    def narrowing(n: int) -> None:
+        # Error: Incompatible value representations in assignment
+        # (expression has type "int", variable has type "float")
+        x: float = 0
+
+        y: float = 0.0  # Ok
+
+        if f():
+            y = n  # Error
+        if f():
+            y = float(n)  # Ok
+
+.. _native-ints:
+
+Native integer types
+--------------------
+
+You can use the native integer types ``i64`` (64-bit signed integer),
+``i32`` (32-bit signed integer), ``i16`` (16-bit signed integer), and
+``u8`` (8-bit unsigned integer) if you know that integer values will
+always fit within fixed bounds. These types are faster than the
+arbitrary-precision ``int`` type, since they don't require overflow
+checks on operations. They may also use less memory than ``int``
+values. The types are imported from the ``mypy_extensions`` module
+(installed via ``pip install mypy_extensions``).
+
+Example::
+
+    from mypy_extensions import i64
+
+    def sum_list(l: list[i64]) -> i64:
+        s: i64 = 0
+        for n in l:
+            s += n
+        return s
+
+    # Implicit conversions from int to i64
+    print(sum_list([1, 3, 5]))
+
+.. note::
+
+  Since there are no overflow checks when performing native integer
+  arithmetic, the above function could result in an overflow or other
+  undefined behavior if the sum might not fit within 64 bits.
+
+  The behavior when running as interpreted Python program will be
+  different if there are overflows. Declaring native integer types
+  have no effect unless code is compiled. Native integer types are
+  effectively equivalent to ``int`` when interpreted.
+
+Native integer types have these additional properties:
+
+* Values can be implicitly converted between ``int`` and a native
+  integer type (both ways).
+
+* Conversions between different native integer types must be explicit.
+  A conversion to a narrower native integer type truncates the value
+  without a runtime overflow check.
+
+* If a binary operation (such as ``+``) or an augmented assignment
+  (such as ``+=``) mixes native integer and ``int`` values, the
+  ``int`` operand is implicitly coerced to the native integer type
+  (native integer types are "sticky").
+
+* You can't mix different native integer types in binary
+  operations. Instead, convert between types explicitly.
+
+For more information about native integer types, refer to
+:ref:`native integer operations <int-ops>`.

jaclang/vendor/mypyc/external/googletest/LICENSE

@@ -0,0 +1,28 @@
+Copyright 2008, Google Inc.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+    * Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above
+copyright notice, this list of conditions and the following disclaimer
+in the documentation and/or other materials provided with the
+distribution.
+    * Neither the name of Google Inc. nor the names of its
+contributors may be used to endorse or promote products derived from
+this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

jaclang/vendor/mypyc/external/googletest/README.md

@@ -0,0 +1,280 @@
+
+### Generic Build Instructions ###
+
+#### Setup ####
+
+To build Google Test and your tests that use it, you need to tell your
+build system where to find its headers and source files.  The exact
+way to do it depends on which build system you use, and is usually
+straightforward.
+
+#### Build ####
+
+Suppose you put Google Test in directory `${GTEST_DIR}`.  To build it,
+create a library build target (or a project as called by Visual Studio
+and Xcode) to compile
+
+    ${GTEST_DIR}/src/gtest-all.cc
+
+with `${GTEST_DIR}/include` in the system header search path and `${GTEST_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} \
+        -pthread -c ${GTEST_DIR}/src/gtest-all.cc
+    ar -rv libgtest.a gtest-all.o
+
+(We need `-pthread` as Google Test uses threads.)
+
+Next, you should compile your test source file with
+`${GTEST_DIR}/include` in the system header search path, and link it
+with gtest and any other necessary libraries:
+
+    g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \
+        -o your_test
+
+As an example, the make/ directory contains a Makefile that you can
+use to build Google Test on systems where GNU make is available
+(e.g. Linux, Mac OS X, and Cygwin).  It doesn't try to build Google
+Test's own tests.  Instead, it just builds the Google Test library and
+a sample test.  You can use it as a starting point for your own build
+script.
+
+If the default settings are correct for your environment, the
+following commands should succeed:
+
+    cd ${GTEST_DIR}/make
+    make
+    ./sample1_unittest
+
+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.
+
+### Using CMake ###
+
+Google Test comes with a CMake build script (
+[CMakeLists.txt](CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for
+cross-platform.). If you don't have CMake installed already, you can
+download it for free from <http://www.cmake.org/>.
+
+CMake works by generating native makefiles or build projects that can
+be used in the compiler environment of your choice.  The typical
+workflow starts with:
+
+    mkdir mybuild       # Create a directory to hold the build output.
+    cd mybuild
+    cmake ${GTEST_DIR}  # Generate native build scripts.
+
+If you want to build Google Test's samples, you should replace the
+last command with
+
+    cmake -Dgtest_build_samples=ON ${GTEST_DIR}
+
+If you are on a \*nix system, you should now see a Makefile in the
+current directory.  Just type 'make' to build gtest.
+
+If you use Windows and have Visual Studio installed, a `gtest.sln` file
+and several `.vcproj` files will be created.  You can then build them
+using Visual Studio.
+
+On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated.
+
+### Legacy Build Scripts ###
+
+Before settling on CMake, we have been providing hand-maintained build
+projects/scripts for Visual Studio, Xcode, and Autotools.  While we
+continue to provide them for convenience, they are not actively
+maintained any more.  We highly recommend that you follow the
+instructions in the previous two sections to integrate Google Test
+with your existing build system.
+
+If you still need to use the legacy build scripts, here's how:
+
+The msvc\ folder contains two solutions with Visual C++ projects.
+Open the `gtest.sln` or `gtest-md.sln` file using Visual Studio, and you
+are ready to build Google Test the same way you build any Visual
+Studio project.  Files that have names ending with -md use DLL
+versions of Microsoft runtime libraries (the /MD or the /MDd compiler
+option).  Files without that suffix use static versions of the runtime
+libraries (the /MT or the /MTd option).  Please note that one must use
+the same option to compile both gtest and the test code.  If you use
+Visual Studio 2005 or above, we recommend the -md version as /MD is
+the default for new projects in these versions of Visual Studio.
+
+On Mac OS X, open the `gtest.xcodeproj` in the `xcode/` folder using
+Xcode.  Build the "gtest" target.  The universal binary framework will
+end up in your selected build directory (selected in the Xcode
+"Preferences..." -> "Building" pane and defaults to xcode/build).
+Alternatively, at the command line, enter:
+
+    xcodebuild
+
+This will build the "Release" configuration of gtest.framework in your
+default build location.  See the "xcodebuild" man page for more
+information about building different configurations and building in
+different locations.
+
+If you wish to use the Google Test Xcode project with Xcode 4.x and
+above, you need to either:
+
+ * update the SDK configuration options in xcode/Config/General.xconfig.
+   Comment options `SDKROOT`, `MACOS_DEPLOYMENT_TARGET`, and `GCC_VERSION`. If
+   you choose this route you lose the ability to target earlier versions
+   of MacOS X.
+ * Install an SDK for an earlier version. This doesn't appear to be
+   supported by Apple, but has been reported to work
+   (http://stackoverflow.com/questions/5378518).
+
+### Tweaking Google Test ###
+
+Google Test 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 Test by
+defining control macros on the compiler command line.  Generally,
+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 [include/gtest/internal/gtest-port.h](include/gtest/internal/gtest-port.h).
+
+### Choosing a TR1 Tuple Library ###
+
+Some Google Test features require the C++ Technical Report 1 (TR1)
+tuple library, which is not yet available with all compilers.  The
+good news is that Google Test implements a subset of TR1 tuple that's
+enough for its own need, and will automatically use this when the
+compiler doesn't provide TR1 tuple.
+
+Usually you don't need to care about which tuple library Google Test
+uses.  However, if your project already uses TR1 tuple, you need to
+tell Google Test 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
+
+to the compiler flags while compiling Google Test and your tests.  If
+you want to force Google Test to use its own tuple library, just add
+
+    -DGTEST_USE_OWN_TR1_TUPLE=1
+
+to the compiler flags instead.
+
+If you don't want Google Test to use tuple at all, add
+
+    -DGTEST_HAS_TR1_TUPLE=0
+
+and all features using tuple will be disabled.
+
+### Multi-threaded Tests ###
+
+Google Test is thread-safe where the pthread library is available.
+After `#include "gtest/gtest.h"`, you can check the `GTEST_IS_THREADSAFE`
+macro to see whether this is the case (yes if the macro is `#defined` to
+1, no if it's undefined.).
+
+If Google Test doesn't correctly detect whether pthread is available
+in your environment, you can force it with
+
+    -DGTEST_HAS_PTHREAD=1
+
+or
+
+    -DGTEST_HAS_PTHREAD=0
+
+When Google Test uses pthread, you may need to add flags to your
+compiler and/or linker to select the pthread library, or you'll get
+link errors.  If you use the CMake script or the deprecated Autotools
+script, this is taken care of for you.  If you use your own build
+script, you'll need to read your compiler and linker's manual to
+figure out what flags to add.
+
+### As a Shared Library (DLL) ###
+
+Google Test is compact, so most users can build and link it as a
+static library for the simplicity.  You can choose to use Google Test
+as a shared library (known as a DLL on Windows) if you prefer.
+
+To compile *gtest* as a shared library, add
+
+    -DGTEST_CREATE_SHARED_LIBRARY=1
+
+to the compiler flags.  You'll also need to tell the linker to produce
+a shared library instead - consult your linker's manual for how to do
+it.
+
+To compile your *tests* that use the gtest shared library, add
+
+    -DGTEST_LINKED_AS_SHARED_LIBRARY=1
+
+to the compiler flags.
+
+Note: while the above steps aren't technically necessary today when
+using some compilers (e.g. GCC), they may become necessary in the
+future, if we decide to improve the speed of loading the library (see
+<http://gcc.gnu.org/wiki/Visibility> for details).  Therefore you are
+recommended to always add the above flags when using Google Test as a
+shared library.  Otherwise a future release of Google Test may break
+your build script.
+
+### Avoiding Macro Name Clashes ###
+
+In C++, macros don't obey namespaces.  Therefore two libraries that
+both define a macro of the same name will clash if you `#include` both
+definitions.  In case a Google Test macro clashes with another
+library, you can force Google Test to rename its macro to avoid the
+conflict.
+
+Specifically, if both Google Test and some other code define macro
+FOO, you can add
+
+    -DGTEST_DONT_DEFINE_FOO=1
+
+to the compiler flags to tell Google Test to change the macro's name
+from `FOO` to `GTEST_FOO`.  Currently `FOO` can be `FAIL`, `SUCCEED`,
+or `TEST`.  For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll
+need to write
+
+    GTEST_TEST(SomeTest, DoesThis) { ... }
+
+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.