diff options
author | Billy Donahue <BillyDonahue@users.noreply.github.com> | 2016-12-18 16:59:12 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2016-12-18 16:59:12 (GMT) |
commit | 5e7fd50e17b6edf1cadff973d0ec68966cf3265e (patch) | |
tree | 0a66a13ac8da76af5eaf5c63215a84386761ddfc | |
parent | c0059a79f82d0ecc3e9bfdc12146a5b84befc70a (diff) | |
parent | cb502b7ad15c9dc9d1f74087a9fc7b6d12177b9b (diff) | |
download | googletest-5e7fd50e17b6edf1cadff973d0ec68966cf3265e.zip googletest-5e7fd50e17b6edf1cadff973d0ec68966cf3265e.tar.gz googletest-5e7fd50e17b6edf1cadff973d0ec68966cf3265e.tar.bz2 |
Merge pull request #658 from audiofanatic/ExternalProject_at_configure_time
Added docs for ExternalProject download during CMake step
-rw-r--r-- | googlemock/README.md | 10 | ||||
-rw-r--r-- | googletest/README.md | 107 |
2 files changed, 115 insertions, 2 deletions
diff --git a/googlemock/README.md b/googlemock/README.md index 332beab..ed500c8 100644 --- a/googlemock/README.md +++ b/googlemock/README.md @@ -125,6 +125,14 @@ build Google Mock and its tests, which has further requirements: ### Building Google Mock ### +If you have CMake available, it is recommended that you follow the +[build instructions][gtest_cmakebuild] +as described for Google Test. If are using Google Mock with an +existing CMake project, the section +[Incorporating Into An Existing CMake Project][gtest_incorpcmake] +may be of particular interest. Otherwise, the following sections +detail how to build Google Mock without CMake. + #### Preparing to Build (Unix only) #### If you are using a Unix system and plan to use the GNU Autotools build @@ -331,3 +339,5 @@ patch. Happy testing! [gtest_readme]: ../googletest/README.md "googletest" +[gtest_cmakebuild]: ../googletest/README.md#using-cmake "Using CMake" +[gtest_incorpcmake]: ../googletest/README.md#incorporating-into-an-existing-cmake-project "Incorporating Into An Existing CMake Project" diff --git a/googletest/README.md b/googletest/README.md index edd4408..0a3474c 100644 --- a/googletest/README.md +++ b/googletest/README.md @@ -59,7 +59,13 @@ 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 +be used in the compiler environment of your choice. You can either +build Google Test as a standalone project or it can be incorporated +into an existing CMake build for another project. + +#### Standalone CMake Project #### + +When building Google Test as a standalone project, the typical workflow starts with: mkdir mybuild # Create a directory to hold the build output. @@ -80,13 +86,110 @@ using Visual Studio. On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated. +#### Incorporating Into An Existing CMake Project #### + +If you want to use gtest in a project which already uses CMake, then a +more 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 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 GoogleTest's source code available to the +main build can be done a few different ways: + +* Download the GoogleTest source code manually and place it at a + known location. This is the least flexible approach and can make + it more difficult to use with continuous integration systems, etc. +* Embed the GoogleTest 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 keep up to date. Some organizations may not + permit this method. +* Add GoogleTest as a git submodule or equivalent. This may not + always be possible or appropriate. Git submodules, for example, + have their own set of advantages and drawbacks. +* Use CMake to download GoogleTest as part of the build's configure + step. This is just a little more complex, but doesn't have the + limitations of the other methods. + +The last of the above methods is implemented with a small piece +of CMake code in a separate file (e.g. `CMakeLists.txt.in`) which +is copied to the build area and then invoked as a sub-build +_during the CMake stage_. That directory is then pulled into the +main build with `add_subdirectory()`. For example: + +New file `CMakeLists.txt.in`: + + cmake_minimum_required(VERSION 2.8.2) + + project(googletest-download NONE) + + include(ExternalProject) + ExternalProject_Add(googletest + GIT_REPOSITORY https://github.com/google/googletest.git + GIT_TAG master + SOURCE_DIR "${CMAKE_BINARY_DIR}/googletest-src" + BINARY_DIR "${CMAKE_BINARY_DIR}/googletest-build" + CONFIGURE_COMMAND "" + BUILD_COMMAND "" + INSTALL_COMMAND "" + TEST_COMMAND "" + ) + +Existing build's `CMakeLists.txt`: + + # Download and unpack googletest at configure time + configure_file(CMakeLists.txt.in googletest-download/CMakeLists.txt) + execute_process(COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" . + RESULT_VARIABLE result + WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download ) + if(result) + message(FATAL_ERROR "CMake step for googletest failed: ${result}") + endif() + execute_process(COMMAND ${CMAKE_COMMAND} --build . + RESULT_VARIABLE result + WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download ) + if(result) + message(FATAL_ERROR "Build step for googletest failed: ${result}") + endif() + + # Prevent overriding the parent project's compiler/linker + # settings on Windows + set(gtest_force_shared_crt ON CACHE BOOL "" FORCE) + + # Add googletest directly to our build. This defines + # the gtest and gtest_main targets. + add_subdirectory(${CMAKE_BINARY_DIR}/googletest-src + ${CMAKE_BINARY_DIR}/googletest-build) + + # The gtest/gtest_main targets carry header search path + # dependencies automatically when using CMake 2.8.11 or + # later. Otherwise we have to add them here ourselves. + if (CMAKE_VERSION VERSION_LESS 2.8.11) + include_directories("${gtest_SOURCE_DIR}/include") + endif() + + # Now simply link against gtest or gtest_main as needed. Eg + add_executable(example example.cpp) + target_link_libraries(example gtest_main) + add_test(NAME example_test COMMAND example) + +Note that this approach requires CMake 2.8.2 or later due to +its use of the `ExternalProject_Add()` command. The above +technique is discussed in more detail in +[this separate article](http://crascit.com/2015/07/25/cmake-gtest/) +which also contains a link to a fully generalized implementation +of the technique. + + ### 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 +instructions in the above sections to integrate Google Test with your existing build system. If you still need to use the legacy build scripts, here's how: |