Как обрабатывать полуотносительные пути включения с помощью cppcheck - PullRequest
Новая
       41

Как обрабатывать полуотносительные пути включения с помощью cppcheck

1 голос
/ 17 февраля 2020

Наш проект C ++ состоит из нескольких модулей (== подпапок), а заголовки располагаются рядом с файлами. cpp: 

CMakeLists.txt
src
│
└───folder1
│   │
│   └───subfolder1
│       │   MyClass1.h
│       │   MyClass1.cpp
│       │   ...
│   
└───folder2
│   │
│   └───subfolder2
│       │   MyClass2.h
│       │   MyClass2.cpp
│       │   ...

Директивы include всегда определяются относительно папки src и не относительно файла кода, например, в MyClass1. cpp: 

#include "folder1/subfolder1/MyClass1.h" // even the own header is defined semi-relatively
#include "folder2/subfolder2/MyClass2.h"

MyClass1::MyClass1() {
// some code
}

Недавно я заметил, что cppcheck (версия 1.89) имеет проблемы с этим и не правильно

  • разрешить макросы, определенные в заголовочном файле -> Ложные жалобы на правильный код
  • найти проблемы с инициализацией члена класса (например, MyClass::MyClass() : _foo(_foo) {}) -> Нет жалоб на неправильный код

При предоставлении -I src для CLI cppcheck, макросы правильно идентифицированы и обнаружены реальные проблемы, подобные описанным выше, но время анализа возрастает с 2 до 20 минут .

Я подозреваю, что, предоставляя все исходный код снова через -I, все файлы повторно анализируются как заголовочные файлы. К сожалению, у меня нет указанной подпапки c include/, которую я могу использовать здесь. Что здесь советуют? Я уже использую несколько заданий: -j 4.

1 Ответ

0 голосов
/ 18 февраля 2020

После некоторого дальнейшего изучения, это может быть неправильный вопрос:

  1. Я вручную взял все файлы заголовков и скопировал их в отдельную папку: find . -type f \( -iname \*.h -o -iname \*.inl -o -iname \*.hpp \) -exec cp --parents \{\} ./../__cppcheckWorkaroundInclude \;, которую я затем предоставил через -I to cppcheck
  2. Проверка все еще заняла 20 минут, поэтому мое предположение, что cppcheck ошибочно сканирует слишком много, неверно - на самом деле это занимает много времени, потому что в нем много кода.
  3. Так что предоставление -I __cppcheckWorkaroundInclude или -I src для cppcheck не имели значения - по крайней мере, я не наблюдал ни одного. Это означает, что -I работает как положено

Для решения проблем с производительностью (я запускаю работу внутри КИ, и 20 минут - это много времени, которое я предпочел бы потратить при выполнении автоматических тестов), я сделал следующее:

  • Уменьшить проверенные конфигурации --max-configs=5
  • Использовал инкрементную проверку через --cppcheck-build-dir=CppcheckBuildDir

К интегрировать это в наш Gitlab CI, я должен был кэшировать этот каталог: 

  cache:
    paths:
      - CppcheckBuildDir

и перед вызовом cppcheck каталог должен быть создан (но с флагом -p, потому что каталог уже может быть там , взято из кеша!): 

mkdir -p CppcheckBuildDir
...