Sync with internal docs
This commit is contained in:
		
							parent
							
								
									1bccd6f353
								
							
						
					
					
						commit
						025f48f89b
					
				@ -1,18 +1,16 @@
 | 
				
			|||||||
 | 
					### Generic Build Instructions
 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Generic Build Instructions ###
 | 
					#### Setup
 | 
				
			||||||
 | 
					
 | 
				
			||||||
#### 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.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
To build Google Test and your tests that use it, you need to tell your
 | 
					#### Build
 | 
				
			||||||
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
 | 
				
			||||||
Suppose you put Google Test in directory `${GTEST_DIR}`.  To build it,
 | 
					compile
 | 
				
			||||||
create a library build target (or a project as called by Visual Studio
 | 
					 | 
				
			||||||
and Xcode) to compile
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
    ${GTEST_DIR}/src/gtest-all.cc
 | 
					    ${GTEST_DIR}/src/gtest-all.cc
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@ -26,98 +24,94 @@ something like the following will do:
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
(We need `-pthread` as Google Test uses threads.)
 | 
					(We need `-pthread` as Google Test uses threads.)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Next, you should compile your test source file with
 | 
					Next, you should compile your test source file with `${GTEST_DIR}/include` in
 | 
				
			||||||
`${GTEST_DIR}/include` in the system header search path, and link it
 | 
					the system header search path, and link it with gtest and any other necessary
 | 
				
			||||||
with gtest and any other necessary libraries:
 | 
					libraries:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \
 | 
					    g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \
 | 
				
			||||||
        -o your_test
 | 
					        -o your_test
 | 
				
			||||||
 | 
					
 | 
				
			||||||
As an example, the make/ directory contains a Makefile that you can
 | 
					As an example, the make/ directory contains a Makefile that you can use to build
 | 
				
			||||||
use to build Google Test on systems where GNU make is available
 | 
					Google Test on systems where GNU make is available (e.g. Linux, Mac OS X, and
 | 
				
			||||||
(e.g. Linux, Mac OS X, and Cygwin).  It doesn't try to build Google
 | 
					Cygwin). It doesn't try to build Google Test's own tests. Instead, it just
 | 
				
			||||||
Test's own tests.  Instead, it just builds the Google Test library and
 | 
					builds the Google Test library and a sample test. You can use it as a starting
 | 
				
			||||||
a sample test.  You can use it as a starting point for your own build
 | 
					point for your own build script.
 | 
				
			||||||
script.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
If the default settings are correct for your environment, the
 | 
					If the default settings are correct for your environment, the following commands
 | 
				
			||||||
following commands should succeed:
 | 
					should succeed:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    cd ${GTEST_DIR}/make
 | 
					    cd ${GTEST_DIR}/make
 | 
				
			||||||
    make
 | 
					    make
 | 
				
			||||||
    ./sample1_unittest
 | 
					    ./sample1_unittest
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you see errors, try to tweak the contents of `make/Makefile` to make
 | 
					If you see errors, try to tweak the contents of `make/Makefile` to make them go
 | 
				
			||||||
them go away.  There are instructions in `make/Makefile` on how to do
 | 
					away. There are instructions in `make/Makefile` on how to do it.
 | 
				
			||||||
it.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Using CMake ###
 | 
					### Using CMake
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Google Test comes with a CMake build script (
 | 
					Google Test comes with a CMake build script (
 | 
				
			||||||
[CMakeLists.txt](https://github.com/google/googletest/blob/master/CMakeLists.txt)) that can be used on a wide range of platforms ("C" stands for
 | 
					[CMakeLists.txt](https://github.com/google/googletest/blob/master/CMakeLists.txt))
 | 
				
			||||||
cross-platform.). If you don't have CMake installed already, you can
 | 
					that can be used on a wide range of platforms ("C" stands for cross-platform.).
 | 
				
			||||||
download it for free from <http://www.cmake.org/>.
 | 
					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
 | 
					CMake works by generating native makefiles or build projects that can be used in
 | 
				
			||||||
be used in the compiler environment of your choice.  You can either
 | 
					the compiler environment of your choice. You can either build Google Test as a
 | 
				
			||||||
build Google Test as a standalone project or it can be incorporated
 | 
					standalone project or it can be incorporated into an existing CMake build for
 | 
				
			||||||
into an existing CMake build for another project.
 | 
					another project.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
#### Standalone CMake Project ####
 | 
					#### Standalone CMake Project
 | 
				
			||||||
 | 
					
 | 
				
			||||||
When building Google Test as a standalone project, the typical
 | 
					When building Google Test as a standalone project, the typical workflow starts
 | 
				
			||||||
workflow starts with:
 | 
					with:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    mkdir mybuild       # Create a directory to hold the build output.
 | 
					    mkdir mybuild       # Create a directory to hold the build output.
 | 
				
			||||||
    cd mybuild
 | 
					    cd mybuild
 | 
				
			||||||
    cmake ${GTEST_DIR}  # Generate native build scripts.
 | 
					    cmake ${GTEST_DIR}  # Generate native build scripts.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you want to build Google Test's samples, you should replace the
 | 
					If you want to build Google Test's samples, you should replace the last command
 | 
				
			||||||
last command with
 | 
					with
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    cmake -Dgtest_build_samples=ON ${GTEST_DIR}
 | 
					    cmake -Dgtest_build_samples=ON ${GTEST_DIR}
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you are on a \*nix system, you should now see a Makefile in the
 | 
					If you are on a \*nix system, you should now see a Makefile in the current
 | 
				
			||||||
current directory.  Just type 'make' to build gtest.
 | 
					directory. Just type 'make' to build gtest.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you use Windows and have Visual Studio installed, a `gtest.sln` file
 | 
					If you use Windows and have Visual Studio installed, a `gtest.sln` file and
 | 
				
			||||||
and several `.vcproj` files will be created.  You can then build them
 | 
					several `.vcproj` files will be created. You can then build them using Visual
 | 
				
			||||||
using Visual Studio.
 | 
					Studio.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated.
 | 
					On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
#### Incorporating Into An Existing CMake Project ####
 | 
					#### Incorporating Into An Existing CMake Project
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you want to use gtest in a project which already uses CMake, then a
 | 
					If you want to use gtest in a project which already uses CMake, then a more
 | 
				
			||||||
more robust and flexible approach is to build gtest as part of that
 | 
					robust and flexible approach is to build gtest as part of that project directly.
 | 
				
			||||||
project directly. This is done by making the GoogleTest source code
 | 
					This is done by making the GoogleTest source code available to the main build
 | 
				
			||||||
available to the main build and adding it using CMake's
 | 
					and adding it using CMake's `add_subdirectory()` command. This has the
 | 
				
			||||||
`add_subdirectory()` command. This has the significant advantage that
 | 
					significant advantage that the same compiler and linker settings are used
 | 
				
			||||||
the same compiler and linker settings are used between gtest and the
 | 
					between gtest and the rest of your project, so issues associated with using
 | 
				
			||||||
rest of your project, so issues associated with using incompatible
 | 
					incompatible libraries (eg debug/release), etc. are avoided. This is
 | 
				
			||||||
libraries (eg debug/release), etc. are avoided. This is particularly
 | 
					particularly useful on Windows. Making GoogleTest's source code available to the
 | 
				
			||||||
useful on Windows. Making GoogleTest's source code available to the
 | 
					 | 
				
			||||||
main build can be done a few different ways:
 | 
					main build can be done a few different ways:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
* Download the GoogleTest source code manually and place it at a
 | 
					*   Download the GoogleTest source code manually and place it at a known
 | 
				
			||||||
  known location. This is the least flexible approach and can make
 | 
					    location. This is the least flexible approach and can make it more difficult
 | 
				
			||||||
  it more difficult to use with continuous integration systems, etc.
 | 
					    to use with continuous integration systems, etc.
 | 
				
			||||||
* Embed the GoogleTest source code as a direct copy in the main
 | 
					*   Embed the GoogleTest source code as a direct copy in the main project's
 | 
				
			||||||
  project's source tree. This is often the simplest approach, but is
 | 
					    source tree. This is often the simplest approach, but is also the hardest to
 | 
				
			||||||
  also the hardest to keep up to date. Some organizations may not
 | 
					    keep up to date. Some organizations may not permit this method.
 | 
				
			||||||
  permit this method.
 | 
					*   Add GoogleTest as a git submodule or equivalent. This may not always be
 | 
				
			||||||
* Add GoogleTest as a git submodule or equivalent. This may not
 | 
					    possible or appropriate. Git submodules, for example, have their own set of
 | 
				
			||||||
  always be possible or appropriate. Git submodules, for example,
 | 
					    advantages and drawbacks.
 | 
				
			||||||
  have their own set of advantages and drawbacks.
 | 
					*   Use CMake to download GoogleTest as part of the build's configure step. This
 | 
				
			||||||
* Use CMake to download GoogleTest as part of the build's configure
 | 
					    is just a little more complex, but doesn't have the limitations of the other
 | 
				
			||||||
  step. This is just a little more complex, but doesn't have the
 | 
					    methods.
 | 
				
			||||||
  limitations of the other methods.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
The last of the above methods is implemented with a small piece
 | 
					The last of the above methods is implemented with a small piece of CMake code in
 | 
				
			||||||
of CMake code in a separate file (e.g. `CMakeLists.txt.in`) which
 | 
					a separate file (e.g. `CMakeLists.txt.in`) which is copied to the build area and
 | 
				
			||||||
is copied to the build area and then invoked as a sub-build
 | 
					then invoked as a sub-build _during the CMake stage_. That directory is then
 | 
				
			||||||
_during the CMake stage_. That directory is then pulled into the
 | 
					pulled into the main build with `add_subdirectory()`. For example:
 | 
				
			||||||
main build with `add_subdirectory()`. For example:
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
New file `CMakeLists.txt.in`:
 | 
					New file `CMakeLists.txt.in`:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@ -176,101 +170,93 @@ Existing build's `CMakeLists.txt`:
 | 
				
			|||||||
    target_link_libraries(example gtest_main)
 | 
					    target_link_libraries(example gtest_main)
 | 
				
			||||||
    add_test(NAME example_test COMMAND example)
 | 
					    add_test(NAME example_test COMMAND example)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Note that this approach requires CMake 2.8.2 or later due to
 | 
					Note that this approach requires CMake 2.8.2 or later due to its use of the
 | 
				
			||||||
its use of the `ExternalProject_Add()` command. The above
 | 
					`ExternalProject_Add()` command. The above technique is discussed in more detail
 | 
				
			||||||
technique is discussed in more detail in 
 | 
					in [this separate article](http://crascit.com/2015/07/25/cmake-gtest/) which
 | 
				
			||||||
[this separate article](http://crascit.com/2015/07/25/cmake-gtest/)
 | 
					also contains a link to a fully generalized implementation of the technique.
 | 
				
			||||||
which also contains a link to a fully generalized implementation
 | 
					 | 
				
			||||||
of the technique.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
##### Visual Studio Dynamic vs Static Runtimes #####
 | 
					##### Visual Studio Dynamic vs Static Runtimes
 | 
				
			||||||
 | 
					
 | 
				
			||||||
By default, new Visual Studio projects link the C runtimes dynamically
 | 
					By default, new Visual Studio projects link the C runtimes dynamically but
 | 
				
			||||||
but Google Test links them statically.
 | 
					Google Test links them statically. This will generate an error that looks
 | 
				
			||||||
This will generate an error that looks something like the following:
 | 
					something like the following: gtest.lib(gtest-all.obj) : error LNK2038: mismatch
 | 
				
			||||||
    gtest.lib(gtest-all.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in main.obj
 | 
					detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value
 | 
				
			||||||
 | 
					'MDd_DynamicDebug' in main.obj
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Google Test already has a CMake option for this: `gtest_force_shared_crt`
 | 
					Google Test already has a CMake option for this: `gtest_force_shared_crt`
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Enabling this option will make gtest link the runtimes dynamically too,
 | 
					Enabling this option will make gtest link the runtimes dynamically too, and
 | 
				
			||||||
and match the project in which it is included.
 | 
					match the project in which it is included.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Legacy Build Scripts ###
 | 
					### Legacy Build Scripts
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Before settling on CMake, we have been providing hand-maintained build
 | 
					Before settling on CMake, we have been providing hand-maintained build
 | 
				
			||||||
projects/scripts for Visual Studio, Xcode, and Autotools.  While we
 | 
					projects/scripts for Visual Studio, Xcode, and Autotools. While we continue to
 | 
				
			||||||
continue to provide them for convenience, they are not actively
 | 
					provide them for convenience, they are not actively maintained any more. We
 | 
				
			||||||
maintained any more.  We highly recommend that you follow the
 | 
					highly recommend that you follow the instructions in the above sections to
 | 
				
			||||||
instructions in the above sections to integrate Google Test
 | 
					integrate Google Test with your existing build system.
 | 
				
			||||||
with your existing build system.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you still need to use the legacy build scripts, here's how:
 | 
					If you still need to use the legacy build scripts, here's how:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
The msvc\ folder contains two solutions with Visual C++ projects.
 | 
					The msvc\ folder contains two solutions with Visual C++ projects. Open the
 | 
				
			||||||
Open the `gtest.sln` or `gtest-md.sln` file using Visual Studio, and you
 | 
					`gtest.sln` or `gtest-md.sln` file using Visual Studio, and you are ready to
 | 
				
			||||||
are ready to build Google Test the same way you build any Visual
 | 
					build Google Test the same way you build any Visual Studio project. Files that
 | 
				
			||||||
Studio project.  Files that have names ending with -md use DLL
 | 
					have names ending with -md use DLL versions of Microsoft runtime libraries (the
 | 
				
			||||||
versions of Microsoft runtime libraries (the /MD or the /MDd compiler
 | 
					/MD or the /MDd compiler option). Files without that suffix use static versions
 | 
				
			||||||
option).  Files without that suffix use static versions of the runtime
 | 
					of the runtime libraries (the /MT or the /MTd option). Please note that one must
 | 
				
			||||||
libraries (the /MT or the /MTd option).  Please note that one must use
 | 
					use the same option to compile both gtest and the test code. If you use Visual
 | 
				
			||||||
the same option to compile both gtest and the test code.  If you use
 | 
					Studio 2005 or above, we recommend the -md version as /MD is the default for new
 | 
				
			||||||
Visual Studio 2005 or above, we recommend the -md version as /MD is
 | 
					projects in these versions of Visual Studio.
 | 
				
			||||||
the default for new projects in these versions of Visual Studio.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
On Mac OS X, open the `gtest.xcodeproj` in the `xcode/` folder using
 | 
					On Mac OS X, open the `gtest.xcodeproj` in the `xcode/` folder using Xcode.
 | 
				
			||||||
Xcode.  Build the "gtest" target.  The universal binary framework will
 | 
					Build the "gtest" target. The universal binary framework will end up in your
 | 
				
			||||||
end up in your selected build directory (selected in the Xcode
 | 
					selected build directory (selected in the Xcode "Preferences..." -> "Building"
 | 
				
			||||||
"Preferences..." -> "Building" pane and defaults to xcode/build).
 | 
					pane and defaults to xcode/build). Alternatively, at the command line, enter:
 | 
				
			||||||
Alternatively, at the command line, enter:
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
    xcodebuild
 | 
					    xcodebuild
 | 
				
			||||||
 | 
					
 | 
				
			||||||
This will build the "Release" configuration of gtest.framework in your
 | 
					This will build the "Release" configuration of gtest.framework in your default
 | 
				
			||||||
default build location.  See the "xcodebuild" man page for more
 | 
					build location. See the "xcodebuild" man page for more information about
 | 
				
			||||||
information about building different configurations and building in
 | 
					building different configurations and building in different locations.
 | 
				
			||||||
different locations.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
If you wish to use the Google Test Xcode project with Xcode 4.x and
 | 
					If you wish to use the Google Test Xcode project with Xcode 4.x and above, you
 | 
				
			||||||
above, you need to either:
 | 
					need to either:
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 * update the SDK configuration options in xcode/Config/General.xconfig.
 | 
					*   update the SDK configuration options in xcode/Config/General.xconfig.
 | 
				
			||||||
    Comment options `SDKROOT`, `MACOS_DEPLOYMENT_TARGET`, and `GCC_VERSION`. If
 | 
					    Comment options `SDKROOT`, `MACOS_DEPLOYMENT_TARGET`, and `GCC_VERSION`. If
 | 
				
			||||||
   you choose this route you lose the ability to target earlier versions
 | 
					    you choose this route you lose the ability to target earlier versions of
 | 
				
			||||||
   of MacOS X.
 | 
					    MacOS X.
 | 
				
			||||||
 * Install an SDK for an earlier version. This doesn't appear to be
 | 
					*   Install an SDK for an earlier version. This doesn't appear to be supported
 | 
				
			||||||
   supported by Apple, but has been reported to work
 | 
					    by Apple, but has been reported to work
 | 
				
			||||||
    (http://stackoverflow.com/questions/5378518).
 | 
					    (http://stackoverflow.com/questions/5378518).
 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Tweaking Google Test ###
 | 
					### Tweaking Google Test
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Google Test can be used in diverse environments.  The default
 | 
					Google Test can be used in diverse environments. The default configuration may
 | 
				
			||||||
configuration may not work (or may not work well) out of the box in
 | 
					not work (or may not work well) out of the box in some environments. However,
 | 
				
			||||||
some environments.  However, you can easily tweak Google Test by
 | 
					you can easily tweak Google Test by defining control macros on the compiler
 | 
				
			||||||
defining control macros on the compiler command line.  Generally,
 | 
					command line. Generally, these macros are named like `GTEST_XYZ` and you define
 | 
				
			||||||
these macros are named like `GTEST_XYZ` and you define them to either 1
 | 
					them to either 1 or 0 to enable or disable a certain feature.
 | 
				
			||||||
or 0 to enable or disable a certain feature.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
We list the most frequently used macros below.  For a complete list,
 | 
					We list the most frequently used macros below. For a complete list, see file
 | 
				
			||||||
see file [include/gtest/internal/gtest-port.h](include/gtest/internal/gtest-port.h).
 | 
					[include/gtest/internal/gtest-port.h](https://github.com/google/googletest/blob/master/include/gtest/internal/gtest-port.h).
 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Choosing a TR1 Tuple Library ###
 | 
					### Choosing a TR1 Tuple Library
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Some Google Test features require the C++ Technical Report 1 (TR1)
 | 
					Some Google Test features require the C++ Technical Report 1 (TR1) tuple
 | 
				
			||||||
tuple library, which is not yet available with all compilers.  The
 | 
					library, which is not yet available with all compilers. The good news is that
 | 
				
			||||||
good news is that Google Test implements a subset of TR1 tuple that's
 | 
					Google Test implements a subset of TR1 tuple that's enough for its own need, and
 | 
				
			||||||
enough for its own need, and will automatically use this when the
 | 
					will automatically use this when the compiler doesn't provide TR1 tuple.
 | 
				
			||||||
compiler doesn't provide TR1 tuple.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
Usually you don't need to care about which tuple library Google Test
 | 
					Usually you don't need to care about which tuple library Google Test uses.
 | 
				
			||||||
uses.  However, if your project already uses TR1 tuple, you need to
 | 
					However, if your project already uses TR1 tuple, you need to tell Google Test to
 | 
				
			||||||
tell Google Test to use the same TR1 tuple library the rest of your
 | 
					use the same TR1 tuple library the rest of your project uses, or the two tuple
 | 
				
			||||||
project uses, or the two tuple implementations will clash.  To do
 | 
					implementations will clash. To do that, add
 | 
				
			||||||
that, add
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
    -DGTEST_USE_OWN_TR1_TUPLE=0
 | 
					    -DGTEST_USE_OWN_TR1_TUPLE=0
 | 
				
			||||||
 | 
					
 | 
				
			||||||
to the compiler flags while compiling Google Test and your tests.  If
 | 
					to the compiler flags while compiling Google Test and your tests. If you want to
 | 
				
			||||||
you want to force Google Test to use its own tuple library, just add
 | 
					force Google Test to use its own tuple library, just add
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    -DGTEST_USE_OWN_TR1_TUPLE=1
 | 
					    -DGTEST_USE_OWN_TR1_TUPLE=1
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@ -282,15 +268,15 @@ If you don't want Google Test to use tuple at all, add
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
and all features using tuple will be disabled.
 | 
					and all features using tuple will be disabled.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Multi-threaded Tests ###
 | 
					### Multi-threaded Tests
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Google Test is thread-safe where the pthread library is available.
 | 
					Google Test is thread-safe where the pthread library is available. After
 | 
				
			||||||
After `#include "gtest/gtest.h"`, you can check the `GTEST_IS_THREADSAFE`
 | 
					`#include "gtest/gtest.h"`, you can check the `GTEST_IS_THREADSAFE` macro to see
 | 
				
			||||||
macro to see whether this is the case (yes if the macro is `#defined` to
 | 
					whether this is the case (yes if the macro is `#defined` to 1, no if it's
 | 
				
			||||||
1, no if it's undefined.).
 | 
					undefined.).
 | 
				
			||||||
 | 
					
 | 
				
			||||||
If Google Test doesn't correctly detect whether pthread is available
 | 
					If Google Test doesn't correctly detect whether pthread is available in your
 | 
				
			||||||
in your environment, you can force it with
 | 
					environment, you can force it with
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    -DGTEST_HAS_PTHREAD=1
 | 
					    -DGTEST_HAS_PTHREAD=1
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@ -298,26 +284,24 @@ or
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
    -DGTEST_HAS_PTHREAD=0
 | 
					    -DGTEST_HAS_PTHREAD=0
 | 
				
			||||||
 | 
					
 | 
				
			||||||
When Google Test uses pthread, you may need to add flags to your
 | 
					When Google Test uses pthread, you may need to add flags to your compiler and/or
 | 
				
			||||||
compiler and/or linker to select the pthread library, or you'll get
 | 
					linker to select the pthread library, or you'll get link errors. If you use the
 | 
				
			||||||
link errors.  If you use the CMake script or the deprecated Autotools
 | 
					CMake script or the deprecated Autotools script, this is taken care of for you.
 | 
				
			||||||
script, this is taken care of for you.  If you use your own build
 | 
					If you use your own build script, you'll need to read your compiler and linker's
 | 
				
			||||||
script, you'll need to read your compiler and linker's manual to
 | 
					manual to figure out what flags to add.
 | 
				
			||||||
figure out what flags to add.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
### As a Shared Library (DLL) ###
 | 
					### As a Shared Library (DLL)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Google Test is compact, so most users can build and link it as a
 | 
					Google Test is compact, so most users can build and link it as a static library
 | 
				
			||||||
static library for the simplicity.  You can choose to use Google Test
 | 
					for the simplicity. You can choose to use Google Test as a shared library (known
 | 
				
			||||||
as a shared library (known as a DLL on Windows) if you prefer.
 | 
					as a DLL on Windows) if you prefer.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
To compile *gtest* as a shared library, add
 | 
					To compile *gtest* as a shared library, add
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    -DGTEST_CREATE_SHARED_LIBRARY=1
 | 
					    -DGTEST_CREATE_SHARED_LIBRARY=1
 | 
				
			||||||
 | 
					
 | 
				
			||||||
to the compiler flags.  You'll also need to tell the linker to produce
 | 
					to the compiler flags. You'll also need to tell the linker to produce a shared
 | 
				
			||||||
a shared library instead - consult your linker's manual for how to do
 | 
					library instead - consult your linker's manual for how to do it.
 | 
				
			||||||
it.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
To compile your *tests* that use the gtest shared library, add
 | 
					To compile your *tests* that use the gtest shared library, add
 | 
				
			||||||
 | 
					
 | 
				
			||||||
@ -325,31 +309,28 @@ To compile your *tests* that use the gtest shared library, add
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
to the compiler flags.
 | 
					to the compiler flags.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
Note: while the above steps aren't technically necessary today when
 | 
					Note: while the above steps aren't technically necessary today when using some
 | 
				
			||||||
using some compilers (e.g. GCC), they may become necessary in the
 | 
					compilers (e.g. GCC), they may become necessary in the future, if we decide to
 | 
				
			||||||
future, if we decide to improve the speed of loading the library (see
 | 
					improve the speed of loading the library (see
 | 
				
			||||||
<http://gcc.gnu.org/wiki/Visibility> for details).  Therefore you are
 | 
					<http://gcc.gnu.org/wiki/Visibility> for details). Therefore you are recommended
 | 
				
			||||||
recommended to always add the above flags when using Google Test as a
 | 
					to always add the above flags when using Google Test as a shared library.
 | 
				
			||||||
shared library.  Otherwise a future release of Google Test may break
 | 
					Otherwise a future release of Google Test may break your build script.
 | 
				
			||||||
your build script.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
### Avoiding Macro Name Clashes ###
 | 
					### Avoiding Macro Name Clashes
 | 
				
			||||||
 | 
					
 | 
				
			||||||
In C++, macros don't obey namespaces.  Therefore two libraries that
 | 
					In C++, macros don't obey namespaces. Therefore two libraries that both define a
 | 
				
			||||||
both define a macro of the same name will clash if you `#include` both
 | 
					macro of the same name will clash if you `#include` both definitions. In case a
 | 
				
			||||||
definitions.  In case a Google Test macro clashes with another
 | 
					Google Test macro clashes with another library, you can force Google Test to
 | 
				
			||||||
library, you can force Google Test to rename its macro to avoid the
 | 
					rename its macro to avoid the conflict.
 | 
				
			||||||
conflict.
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
Specifically, if both Google Test and some other code define macro
 | 
					Specifically, if both Google Test and some other code define macro FOO, you can
 | 
				
			||||||
FOO, you can add
 | 
					add
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    -DGTEST_DONT_DEFINE_FOO=1
 | 
					    -DGTEST_DONT_DEFINE_FOO=1
 | 
				
			||||||
 | 
					
 | 
				
			||||||
to the compiler flags to tell Google Test to change the macro's name
 | 
					to the compiler flags to tell Google Test to change the macro's name from `FOO`
 | 
				
			||||||
from `FOO` to `GTEST_FOO`.  Currently `FOO` can be `FAIL`, `SUCCEED`,
 | 
					to `GTEST_FOO`. Currently `FOO` can be `FAIL`, `SUCCEED`, or `TEST`. For
 | 
				
			||||||
or `TEST`.  For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll
 | 
					example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll need to write
 | 
				
			||||||
need to write
 | 
					 | 
				
			||||||
 | 
					
 | 
				
			||||||
    GTEST_TEST(SomeTest, DoesThis) { ... }
 | 
					    GTEST_TEST(SomeTest, DoesThis) { ... }
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
				
			|||||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user