2014-12-03 2 views
2

Я пытаюсь собрать покрытие кода для проекта с кодом C++ и c как на Ubuntu.gcov генерирует пустое покрытие для c

Я использую значения '-fprofile-arcs' и '-ftest-coverage' как CXXFLAGS и CFLAGS; '-lgcov' как LINKFLAGS.

Common C Структура проекта:

c_code\ 
    src 
    unit_tests 

ЦСИ содержит источники статической библиотеки.

unit_tests dir содержат тесты, написанные с помощью googletest framework e. г. испытания вида

TEST_F(test_case_name, test_name) { 
    some_gtest_assertions; 
} 

После сборки бинарного файла googletest, который должен содержать статическую библиотеку для проверки внутри нее.

Создание и запуск двоичных файлов проекта приводит к генерации файлов * .gcno и * .gcda. Однако мои результаты покрытия C пусты (C++ генерируется хорошо).

команда lcov имеет формат folloiwng:

lcov --capture --directory my_c_gcda_location --output-file c_coverage.info 

Журналы lcov показывают следующие за C-связанных файлов gcda:.

gcov не создает каких-либо файлов для «my_c_gcda_location/* gcda «`

Есть также ошибки типа:

* .gcda: марка несовпадение с примечаниями файл

Должен ли я указать некоторые дополнительные параметры или выполнить некоторые дополнительные действия, чтобы получить результаты покрытия для C? Или что может быть причиной этих проблем?

+0

Вам нужно будет предоставить «минимальный проверяемый код», показывающий, как «my_c_gcda_location» выполняет обработку/создание файлов - или никто не может ничего сделать, кроме угадывания. Вопросы без четкого описания проблемы не полезны другим читателям. См.: [** Как создать минимальный, завершенный и проверяемый пример **] (http://stackoverflow.com/help/mcve). " –

ответ

0

Вы можете получить «несоответствие марке», когда файлы .gcda новее, чем файлы .gcno.

Это может произойти главным образом по двум причинам: 1. После запуска теста и перед созданием файла трассировки вы можете восстановить код. 2. Бинарный файл может быть встроен в одну машину, а тест запущен на другой машине, время которой опережает строительную машину.

Для этих двух случаев вам нужно просто убедиться, что время создания файла .gcda больше, чем файлы .gcno и .c *.

Вы можете сделать это, просто сделав «touch * .gcda», а затем запустите команду lcov.

+0

Наконец, я узнал, где было вызвано второе восстановление (статические и общие библиотеки были построены как). Отключение создания разделяемых библиотек (поскольку охват на статике был достаточным для моих целей), разрешенная проблема – Evgeny

+0

touch не работает, похоже, что метка времени находится в фактическом содержимом файла (по сравнению с временной меткой inode) т.е.'hexdump -e '"% x \ n "' -s8 -n4 myclass.gcda'. См. Http://bobah.net/d4d/tools/code-coverage-with-gcov - Устранение неполадок. –

Смежные вопросы