- Cmake include gtest and gmock manual#
- Cmake include gtest and gmock code#
- Cmake include gtest and gmock download#
These are simply forcing CMake to immediately fully process the CMakeLists.txt file we copied rather than waiting until build time. Another key feature is the way we invoke CMake to setup and execute a sub-build of the CMakeLists.txt file we just copied (this is what the two execute_process() commands are doing).
The configure_file() command also does variable substitution, so the actual value of CMAKE_BINARY_DIR will be replaced with the current value when the file is copied. The configure_file() command copies our template file to the build area and the target file name must be CMakeLists.txt (the add_subdirectory() command requires this). # Now simply link your own targets against gtest, gmock,Ī few key features should be noted. A simplified version of the regular ExternalProject approach looks something like this (adapted from a more complete example implementation available here, but using a now outdated URL): include(ExternalProject) In reality, the typical way ExternalProject is used results in a separate, self-contained sub-build which your CMake project essentially sees as a black box. This is unfortunate, since this is precisely the sort of thing CMake is supposed to be doing for you. to make it seem like gtest is a fully integrated part of your build.
Cmake include gtest and gmock code#
This means you end up manually adding additional CMake code to define the libraries, import targets, etc. The gtest library is created as part of your build, but not in a way which makes the CMake targets available to you automatically.
Cmake include gtest and gmock download#
When a fully integrated download and build of gtest is required, typical advice for building it as part of your CMake project is based around using ExternalProject. I’ll focus for the moment on gtest, since it’s a little simpler than gmock, but the concepts are similar for both. See the FindGTest and GoogleTest modules for more information on this approach, which is simple and provides some nice extra features for defining tests. it is provided by the system or you are happy to manually build it outside of your project), then CMake makes it trivial to bring gtest into your project with the find_package() command. The approach is general enough to be applied to any CMake-based external project, not just gtest/gmock.īefore proceeding, I should highlight that if you are only interested in gtest and you do have a pre-built gtest available (e.g.
Cmake include gtest and gmock manual#
Unlike other common approaches, no manual information has to be provided other than the package to download. This article demonstrates a convenient way to add them with automated source download and have them build directly as part of your project using add_subdirectory(). Not so awesome is when you don’t have a pre-built gtest/gmock available to use.
The module documentation uses GoogleTest in some of its examples. The generalised implementation was extended further and became the FetchContent module, which was added to CMake in 3.11. I’ve also revised the general purpose implementation to make it more flexible, expanded its documentation and made it available on Github under a MIT license. I’ve updated the content here to reflect the changes and the article now also covers both gtest and gmock. Since the original article was written, gtest and gmock have been merged and moved into a single repository on Github under the name GoogleTest.
0 kommentar(er)
