Quickstart: Building with CMake
This tutorial aims to get you up and running with GoogleTest using CMake. If you’re using GoogleTest for the first time or need a refresher, we recommend this tutorial as a starting point. If your project uses Bazel, see the Quickstart for Bazel instead.
Prerequisites
To complete this tutorial, you’ll need:
- A compatible operating system (e.g. Linux, macOS, Windows).
- A compatible C++ compiler that supports at least C++14.
- CMake and a compatible build tool for building the project.
- Compatible build tools include Make, Ninja, and others — see CMake Generators for more information.
See Supported Platforms for more information about platforms compatible with GoogleTest.
If you don’t already have CMake installed, see the CMake installation guide.
Note: The terminal commands in this tutorial show a Unix shell prompt, but the commands work on the Windows command line as well.
Set up a project
CMake uses a file named CMakeLists.txt to configure the build system for a project. You’ll use this file to set up your project and declare a dependency on GoogleTest.
First, create a directory for your project:
$ mkdir my_project && cd my_project
Next, you’ll create the CMakeLists.txt file and declare a dependency on GoogleTest. There are many ways to express dependencies in the CMake ecosystem; in this quickstart, you’ll use the FetchContent CMake module. To do this, in your project directory ( my_project ), create a file named CMakeLists.txt with the following contents:
cmake_minimum_required(VERSION 3.14) project(my_project) # GoogleTest requires at least C++14 set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) include(FetchContent) FetchContent_Declare( googletest URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip ) # For Windows: Prevent overriding the parent project's compiler/linker settings set(gtest_force_shared_crt ON CACHE BOOL "" FORCE) FetchContent_MakeAvailable(googletest)
The above configuration declares a dependency on GoogleTest which is downloaded from GitHub. In the above example, 03597a01ee50ed33e9dfd640b249b4be3799d395 is the Git commit hash of the GoogleTest version to use; we recommend updating the hash often to point to the latest version.
For more information about how to create CMakeLists.txt files, see the CMake Tutorial.
Create and run a binary
With GoogleTest declared as a dependency, you can use GoogleTest code within your own project.
As an example, create a file named hello_test.cc in your my_project directory with the following contents:
#include // Demonstrate some basic assertions. TEST(HelloTest, BasicAssertions) // Expect two strings not to be equal. EXPECT_STRNE("hello", "world"); // Expect equality. EXPECT_EQ(7 * 6, 42); >
GoogleTest provides assertions that you use to test the behavior of your code. The above sample includes the main GoogleTest header file and demonstrates some basic assertions.
To build the code, add the following to the end of your CMakeLists.txt file:
enable_testing() add_executable( hello_test hello_test.cc ) target_link_libraries( hello_test GTest::gtest_main ) include(GoogleTest) gtest_discover_tests(hello_test)
The above configuration enables testing in CMake, declares the C++ test binary you want to build ( hello_test ), and links it to GoogleTest ( gtest_main ). The last two lines enable CMake’s test runner to discover the tests included in the binary, using the GoogleTest CMake module.
Now you can build and run your test:
my_project$ cmake -S . -B build -- The C compiler identification is GNU 10.2.1 -- The CXX compiler identification is GNU 10.2.1 . -- Build files have been written to: . /my_project/build my_project$ cmake --build build Scanning dependencies of target gtest . [100%] Built target gmock_main my_project$ cd build && ctest Test project . /my_project/build Start 1: HelloTest.BasicAssertions 1/1 Test #1: HelloTest.BasicAssertions . Passed 0.00 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.01 sec
Congratulations! You’ve successfully built and run a test binary using GoogleTest.
Next steps
- Check out the Primer to start learning how to write simple tests.
- See the code samples for more examples showing how to use a variety of GoogleTest features.
Как через cmake добавить cpplint и gtest?
Гугл тесты..
Опишу суть моих действий.
в git bash:
$git clone
далее:
Создаю в корневой папку ‘build’. Захожу, открываю через папку cmd и перед тем, как прописать команду(которую скинул выше) — знаю, что необходимо сначала установить cpplint.
Качаю файл cpplint.py, кидаю его в C:\Users\pichu\AppData\Local\Programs\Python\Python310\Scripts
через эту папку открываю cmd и прописываю:
pip install cpplint
Скачивание завершено. Проверил командой, выдало список команд данного скрипта.
Вставляю команду (которую скинул в начале) в cmd строку (по папке репозитория в build).
Начался процесс. Всё загрузилось и под конец мне выдало сообщение о том, что cpplint не был найден, и еще 2 ошибки ниже:
- Вопрос задан более двух лет назад
- 221 просмотр
Комментировать
Решения вопроса 1
allvis @allvis Автор вопроса
Решил проблему, в конце команды отключил чекер
cmake -D USE_SEQ=ON -D USE_MPI=ON -D USE_OMP=ON -D USE_TBB=ON -D USE_STD=ON -D USE_STYLE_CHECKER=ON ..
на
cmake -D USE_SEQ=ON -D USE_MPI=ON -D USE_OMP=ON -D USE_TBB=ON -D USE_STD=ON -D USE_STYLE_CHECKER=OFF..Ответ написан более двух лет назад
Комментировать
Нравится Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- C++
- +1 ещё
Сmake не подключаеться библиотека curses,что делать?
- 1 подписчик
- 09 янв.
- 94 просмотра
Toliak / Guide.md
Чтобы установить значение опции, отличное от «по умолчанию», необходимо дописать -DНАЗВАНИЕ_ОПЦИИ=Значение к команде конфигурирования. Команда после этого может выглядеть, например, так:
cmake -H. -B.build -DBUILD_DEMO=On
Чтобы сделать такое действие в CLion, необходимо перейти в: Settings -> CMake -> CMake options.
Если используется Hunter (пакетный менеджер), то прописываются его настройки
include("tools/gate/cmake/HunterGate.cmake") # Подключение CMake скрипта с дополнительными функциями HunterGate( URL "https://github.com/ruslo/hunter/archive/v0.23.214.tar.gz" # URL к ядру Hunter SHA1 "e14bc153a7f16d6a5eeec845fb0283c8fad8c358" # SHA1 хэш )
На этапе конфигурирования, CMake ожидает файл tools/gate/cmake/HunterGate.cmake .
Если этот файл не существует, возможны 2 варианта:
- Необходимо добавить гит подмодуль:
git submodule add https://github.com/hunter-packages/gate.git tools/gate
- Либо (если используется шаблонный репозиторий) необходимо обновить подмодули:
git submodule update —init —recursive
URL и SHA1 ядра Hunter можно получить в релизах: https://github.com/hunter-packages/gate.git
project(MyAwesomeProject)
Дополнительные опции для компилятора (могут отсутствовать)
string(APPEND CMAKE_CXX_FLAGS " -Wall -Werror") # Флаги для включения всех предупреждений и дропа компиляции при их наличии
Подключение зависимых библиотек
Затем осуществляется подключение библиотек, в которых нуждается проект (Boost, GTest, Threads и т.д.)
Указания для Hunter о необходимо коллекционирования указанных пакетов
hunter_add_package(GTest) # Указание Hunter о добавлении пакета GTest hunter_add_package(Boost COMPONENTS filesystem regex) # Указание Hunter о добавлении пакета Boost с указанными компонентами
Указания о том, какие пакеты будут использованы (ожидается их наличие)
find_package(GTest CONFIG REQUIRED) find_package(Boost CONFIG REQUIRED filesystem regex) find_package(Threads REQUIRED)
CONFIG — ключевое слово, показывающее маску названий конфигурационных файлов.
REQUIRED — обязательность подключения пакета (иначе — ошибка).
Добавление целей сборки
После настройки окружающией среды пишется информация о том, что ожидается получить в результате сборки
add_executable( my_very_interesting_target # Название цели $ /path_to_cpp_file $ /path_to_another_cpp_file )
add_library( my_very_interesting_target_library # Название цели STATIC # Тип библиотеки (SHARED или STATIC) $ /path_to_cpp_file $ /path_to_another_cpp_file )
Указание директорий с заголовочными файлами
target_include_directories( target_name # Цель, при сборке которой учитываются указанные пути к заголовочным файлам PUBLIC # область видимости (PRIVATE, INTERFACE или PUBLIC) $ /include )
Указание библиотек для линковки
target_link_libraries( target_name # Цель, к которой просходит линковка library_name # Библиотеки, которые линкуются к цели )
Названия библиотек из Hunter, как правило, имеют вид LibraryName::ComponentName .
Данные о библиотеках из пакета, добавленного через find_package хранятся в переменных. Например, для Threads: $
Для сборки тестирования необходимо наличие:
- Добавления пакета googletest (GTest в Hunter)
- Цели для сборки исполняемого файла
- Линковки gtest_main и gtest (GTest::main и GTest::gtest в Hunter) к цели
- Включенного тестирования в конфигурационном файле
enable_testing() # Включение тестирования add_test(NAME unit_tests COMMAND tests) # При тестировании выполнится исполняемый файл tests
Можно добавлять несколько тестовых целей под разными названиями. И даже с использованием разных фреймворков.
Для сборки и выполнения тестирования необходимо выполнить следующую команду (ожидается предварительное конфигурирование):
cmake --build .build --target test
Пример тела конфигурационного файла с тестированием:
# 1 hunter_add_package(GTest) find_package(GTest CONFIG REQUIRED) find_package(Threads) # 2 add_executable( tests $ /tests/test.cpp ) # 3 target_link_libraries( tests $ GTest::gtest GTest::main ) # 4 enable_testing() add_test(NAME unit_tests COMMAND tests)
Для удобства в CLion необходимо добавить конфигурацию сборки google test.
Начало конфигурации. Как правило, его трогать не надо.
if (BUILD_COVERAGE) # Если активна опция сборки с покрытием set(ENABLE_COVERAGE ON CACHE BOOL "Enable coverage build." FORCE) # Установка значения переменной ENABLE_COVERAGE list(APPEND CMAKE_MODULE_PATH "$ /cmake") # Дополнение возможных местоположений конфигурационных cmake файлов find_package(codecov) # Нахождение пакета (ожидается существование файла cmake/FindCodecov.cmake)
Далее прописываются цели, которые будут проанализированы на процент покрытия.
add_coverage(my_awesome_and_very_interesting_target) add_coverage(tests)
Конец конфигурации. Как правило, не надо трогать.
list(APPEND LCOV_REMOVE_PATTERNS "'$ /tests/*'") # Удаление файлов с тестами из анализа coverage_evaluate() # Вызов анализатора endif ()
Для начала необходимо настроить окружение. Как правило, это не надо трогать
os: linux # ОС sudo: required # Необходимость прав sudo language: "minimal" # Языковой шаблон services: - docker # Необходимые сервисы env: # Based on Ubuntu 18.04 # GCC 7.3 # clang 7 # CMake 3.10 # gcovr # jscpd # cpplint - DOCKER_IMAGE="rusdevops/bootstrap:cpp" # Используется по умолчанию # Based on Alpine 3.10 # GCC 8.3 # CMake 3.14 # gcovr # jscpd # valgrind # Hunter GTest v1.8.0 (cached) # Hunter Boost cached components: exception # filesystem # log # regex # system # - DOCKER_IMAGE="toliak/bootstrap-cpp" # Для использования снять комментарий before_script: - docker pull $DOCKER_IMAGE # Предварительное скачивание образа
Далее необходимо указать jobs’ы, которые будет выполнять Travis. Jobs содержит название и команды.
jobs: include: - name: "tests" # Название script: # Команды для исполнения - docker run -t -v $(pwd):/var/builder/ -w /var/builder --entrypoint ./scripts/tests.sh $DOCKER_IMAGE - name: "quality" script: - docker run -t -v $(pwd):/var/builder/ -w /var/builder --entrypoint ./scripts/duplication.sh $DOCKER_IMAGE # И так далее
К таким относятся, например, правила для веток и для уведомлений. Например:
notifications: email: false
Настройка рабочей среды
Для установки библиотеки GTest в Windows 10 скачаем ее исходный код, скомпилируем с помощью CMake и подключим собранную библиотеку и заголовочные файлы к MinGW.
Убедитесь в том, что в системе установлены MinGW и CMake.
Скачайте zip архив со страницы релиза (версия 1.11.0 на момент написания текста). Ссылка находится в самом низу страницы.
Распакуйте архив и перейдите в директорию, содержащую файл CMakeLists.txt . Выполняем сборку с помощью следующих команд (используйте интерфейс PowerShell):
> mkdir build; # создаем директорию для сборки > cd build; # переходим в директорию build > cmake -G "MinGW Makefiles" .. # генерируем файлы для сборки > cmake --build . # запускаем сборку
Подключаем библиотеку к MinGW:
- Скопируйте директорию googletest/include/gtest , в директорию MinGW, которая у автора этого текста выглядит так mingw32/lib/gcc/i686-w64-mingw32/8.1.0/include/ .
- Скопируйте содержимое директории build/lib (четыре файла с расширением .a ) в директорию MinGW mingw32/lib/ .
Готово. Теперь Вы можете подключать библиотеку GTest к своим проектам.
- Введение
- Настройка рабочей среды
- Установка и настройка VS Code
- Что такое Git?
- Установка Git for Windows
- Установка компилятора
- Установка CMake
- Установка Miniconda3
- Установка библиотеки GoogleTest
- Как отправлять решение задач