mirror of
https://github.com/google/googletest.git
synced 2024-12-27 18:31:21 +08:00
Improve the tutorial that may be confusing
This commit is contained in:
parent
a4ab0abb93
commit
7aae2ac34c
@ -21,7 +21,7 @@ is now available.
|
|||||||
|
|
||||||
## Welcome to **Google Test**, Google's C++ test framework!
|
## Welcome to **Google Test**, Google's C++ test framework!
|
||||||
|
|
||||||
This repository is a merger of the formerly separate GoogleTest and GoogleMock
|
This repository is a merger of the formerly separate Google Test and Google Mock
|
||||||
projects. These were so closely related that it makes sense to maintain and
|
projects. These were so closely related that it makes sense to maintain and
|
||||||
release them together.
|
release them together.
|
||||||
|
|
||||||
@ -98,7 +98,7 @@ is a VS Code extension allowing to view Google Tests in a tree view, and
|
|||||||
run/debug your tests.
|
run/debug your tests.
|
||||||
|
|
||||||
[C++ TestMate](https://github.com/matepek/vscode-catch2-test-adapter) is a VS
|
[C++ TestMate](https://github.com/matepek/vscode-catch2-test-adapter) is a VS
|
||||||
Code extension allowing to view Google Tests in a tree view, and run/debug your
|
Code extension allowing to view Google Test in a tree view, and run/debug your
|
||||||
tests.
|
tests.
|
||||||
|
|
||||||
[Cornichon](https://pypi.org/project/cornichon/) is a small Gherkin DSL parser
|
[Cornichon](https://pypi.org/project/cornichon/) is a small Gherkin DSL parser
|
||||||
|
@ -24,17 +24,20 @@ another project.
|
|||||||
When building Google Test as a standalone project, the typical workflow starts
|
When building Google Test as a standalone project, the typical workflow starts
|
||||||
with:
|
with:
|
||||||
|
|
||||||
mkdir mybuild # Create a directory to hold the build output.
|
git clone https://github.com/google/googletest.git -b release-1.10.0
|
||||||
cd mybuild
|
cd googletest
|
||||||
cmake ${GTEST_DIR} # Generate native build scripts.
|
mkdir build # Create a directory to hold the build output.
|
||||||
|
cd build
|
||||||
If you want to build Google Test's samples, you should replace the last command
|
cmake .. # Generate native build scripts for Google Test
|
||||||
with
|
|
||||||
|
|
||||||
cmake -Dgtest_build_samples=ON ${GTEST_DIR}
|
|
||||||
|
|
||||||
If you are on a \*nix system, you should now see a Makefile in the current
|
If you are on a \*nix system, you should now see a Makefile in the current
|
||||||
directory. Just type 'make' to build gtest.
|
directory. Just type `make` to build gtest.
|
||||||
|
|
||||||
|
make
|
||||||
|
|
||||||
|
And if you are a system administrator, you can simply install Google Test.
|
||||||
|
|
||||||
|
sudo make install # Install in /usr/local/ by default
|
||||||
|
|
||||||
If you use Windows and have Visual Studio installed, a `gtest.sln` file and
|
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
|
several `.vcproj` files will be created. You can then build them using Visual
|
||||||
@ -44,26 +47,31 @@ 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 more
|
The easiest way to use Google Test is importing installed libraries and headers.
|
||||||
robust and flexible approach is to build gtest as part of that project directly.
|
|
||||||
This is done by making the GoogleTest source code available to the main build
|
* Import Google Test by using `find_package` (or `pkg_check_modules`).
|
||||||
and adding it using CMake's `add_subdirectory()` command. This has the
|
For example, if `find_package(GTest CONFIG REQUIRED)` is succeed,
|
||||||
significant advantage that the same compiler and linker settings are used
|
you can use the libraries as `GTest::gtest`, `GTest::gmock`.
|
||||||
between gtest and the rest of your project, so issues associated with using
|
|
||||||
incompatible libraries (eg debug/release), etc. are avoided. This is
|
And a more robust and flexible approach is to build gtest as part of that project
|
||||||
particularly useful on Windows. Making GoogleTest's source code available to the
|
directly. This is done by making the Google Test source code available to the
|
||||||
|
main build and adding it using CMake's `add_subdirectory()` command.
|
||||||
|
This has the significant advantage that the same compiler and linker settings
|
||||||
|
are used between gtest and the rest of your project, so issues associated with
|
||||||
|
using incompatible libraries (eg debug/release), etc. are avoided. This is
|
||||||
|
particularly useful on Windows. Making Google Test'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 known
|
* Download the Google Test source code manually and place it at a known
|
||||||
location. This is the least flexible approach and can make it more difficult
|
location. This is the least flexible approach and can make 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 project's
|
* Embed the Google Test source code as a direct copy in the main project's
|
||||||
source tree. This is often the simplest approach, but is also the hardest to
|
source tree. This is often the simplest approach, but is also the hardest to
|
||||||
keep up to date. Some organizations may not permit this method.
|
keep up to date. Some organizations may not permit this method.
|
||||||
* Add GoogleTest as a git submodule or equivalent. This may not always be
|
* Add Google Test as a git submodule or equivalent. This may not always be
|
||||||
possible or appropriate. Git submodules, for example, have their own set of
|
possible or appropriate. Git submodules, for example, have their own set of
|
||||||
advantages and drawbacks.
|
advantages and drawbacks.
|
||||||
* Use CMake to download GoogleTest as part of the build's configure step. This
|
* Use CMake to download Google Test as part of the build's configure step. This
|
||||||
is just a little more complex, but doesn't have the limitations of the other
|
is just a little more complex, but doesn't have the limitations of the other
|
||||||
methods.
|
methods.
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user