Перекрестное профилирование с gcov, но GCOV_PREFIX и GCOV_PREFIX_STRIP игнорируется
Я хочу использовать GCOV для покрытия кода, но тесты будут выполняться на другой машине. Таким образом, жесткий проводной путь к файлам.gcda в исполняемом файле не будет работать.
Чтобы изменить этот каталог по умолчанию, я могу использовать env-переменные GCOV_PREFIX и GCOV_PREFIX_STRIP, как сказано здесь.
Вот мои команды, которые я использовал:
$ export GCOV_PREFIX="/foo/bar"
$ export GCOV_PREFIX_STRIP="3"
$ gcc main.c -fprofile-arcs -ftest-coverage
$ strings a.out | grep gcda
/home/calmarius/blahblah/main.c.gcda
Путь остается прежним. Кто-нибудь имеет опыт работы с этим?
2 ответа
Переменные среды учитываются при запуске кода.
Установите соответствующие значения на целевом компьютере, прежде чем запускать тесты, и .gcda файлы будут генерироваться там, где вы хотите.
************ ARRRRGGGGGHHHHH ************
Пожалуйста, пожалуйста, проголосуйте за ответ Мэта.
Переменные среды учитываются при запуске кода.
Это одно предложение, очевидно, отсутствует в КАЖДОММ документе, который я прочитал о том, как переместить вывод!
На самом деле, позвольте мне немного расширить этот ответ.
GCOV_PREFIX - это переменная окружения времени выполнения, в отличие от времени создания, которая определяет корневой каталог, в который записываются выходные файлы gcov (*.gcda).
GCOV_PREFIX_STRIP = X также является переменной времени выполнения и позволяет удалять элементы X из пути, найденного в объектных файлах (строки XXXX.o)
Что это значит:
Когда вы строите свой проект, объектные файлы записываются с полным путем к местоположению каждого исходного файла, отвечающего за каждый вложенный в них объектный файл.
Итак, представьте, что вы пишете исполняемый файл MyApp и библиотеку MyLib в строгой структуре каталога следующим образом:
/MyProject
|-MyApp
|--MyLib
Обратите внимание, MyLib является подкаталогом MyApp
Допустим, MyApp имеет 2 исходных файла, а MyLib - 3
После сборки с флагом "-coverage" вы сгенерируете 5 файлов.gcno, по 1 для каждого объектного файла.
В файлах.o для MyApp будет указан абсолютный путь **/MyProject/MyApp/**a_source_file.cpp Аналогично, в файлах.o для MyLib будет указан путь **/MyProject/MyApp/MyLib/**another_source_file.cpp
Теперь предположим, что вы похожи на меня, и переместите эти файлы на совершенно другую машину с другой структурой каталогов, из которой они были созданы. В моем случае целевая машина на самом деле совершенно другой архитектуры. Я разверну в /some/deploy/path not /MyProject на этой машине.
Если вы просто запустите приложение, gcov data попытается записать соответствующие файлы.gcda в / MyProject / MyApp и / MyProject / MyApp / MyLib для каждого объектного файла в вашем проекте, потому что это путь, указанный в файлах.o, и после all, MyApp и MyLib - это просто коллекции файлов.o, заархивированных вместе, с некоторыми другими средствами для исправления функциональных указателей и прочего.
Скорее всего, эти каталоги не существуют, и вы, вероятно, не являетесь пользователем root (не так ли), поэтому эти каталоги также не будут созданы. Ооооо... вы не увидите никаких файлов gcda в месте развертывания / my / deploy / path.
Это совершенно сбивает с толку, верно!?!??!?!?!?
Здесь вступают GCOV_PREFIX и GCOV_PREFIX_STRIP.
(БАМ! Кулак бьёт по лбу) Вам нужно указать **** время выполнения ****, что встроенный путь в.o-файлах не совсем то, что вам нужно. Вы хотите "удалить" часть пути и заменить его каталогом deploy.
Таким образом, вы устанавливаете каталог deploy с помощью GCOV_PREFIX=/some/deploy/path и хотите удалить / MyProject из сгенерированных путей.gcda, чтобы установить GCOV_PREFIX_STRIP=1
С этими двумя установленными переменными среды вы запускаете свое приложение и затем смотрите в /some/deploy/path/MyApp и /some/deploy/path/MyApp/MyLib и вот, чудеса появляются 5 gcda-файлов, по одному для каждого объекта файл.
Примечание: проблема усложняется, если вы делаете из исходных сборок..O указывает на источник, но gcda будет записан относительно каталога сборки.