Если в ваше решение (solution) входит много больших проектов, то работа с анализатором PVS-Studio может стать некомфортной. В этой небольшой заметке мы рассмотрим, почему это происходит и как можно исправить ситуацию, интегрировав PVS-Studio в сборочный процесс MSBuild.
Сразу хочется подчеркнуть, что описанный ниже режим работы анализатора имеет смысл использовать только в исключительных случаях. Для маленьких и средних проектов выгоды от его использования не будет. Даже наоборот, можно существенно увеличить время, требующееся для анализа исходного кода.
Но будем считать, что у вас именно тот самый случай. В solution включено большое количество проектов. Общее количество компилируемых файлов исчисляется многими тысячами.
Анализатор PVS-Studio использует функции API, предоставляемые Visual Studio, чтобы собрать информацию о файлах. Он должен узнать, какие файлы следует проверять, какие директивы препроцессора заданы для каждого файла, какие директории с заголовочными файлами нужно использовать и так далее.
Если проектов и файлов много, то сбор информации начинает занимать существенное время. PVS-Studio надолго задумывается перед началом анализа файлов. Особенно это заметно при использовании инкрементального анализа. Часто получается, что сбор информации идёт в несколько раз дольше, чем сам анализ нескольких изменившихся файлов.
Сделать с этим мы ничего не можем, так как не можем ускорить вызовы API функций. Однако существует обходной путь. Это интеграция со сборочным процессом MSBuild.
В этой заметке мы не будем рассматривать, как начать использовать MSBuild. Это очень подробно описано в документации. Нет смысла копировать оттуда текст. Со временем что-то может измениться и заметка в блоге устареет. Поэтому отсылаем читателя за более подробной информацией к разделу в документации: "Прямая интеграция анализа PVS-Studio в сборочный процесс MSBuild. Режим интеграции MSBuild в Visual Studio IDE".
Здесь же отметим только достоинства и недоставки интеграции.
Достоинства:
1) Анализатору не нужно собирать информацию о файлах. Всю необходимую информацию ему сообщает MSBuild. Это может существенно сократить время анализа в проектах с огромным количеством файлов.
2) В случае инкрементального анализа MSBuild запустит проверку только для изменённых файлов и предоставит всю необходимую информацию. Соответственно, на больших проектах можно комфортно использовать режим инкрементального анализа.
3) Можно проверить проекты, которые являются расширением стандартной проектной модели Visual C++. Например, проекты драйверов. Любой пользователь Visual C++ может расширить проектную модель для добавления каких-нибудь своих специфичных параметров сборки. Но, если проект собирается через MSBuild, в него может быть встроена проверка PVS-Studio. Обычная же проверка PVS-Studio через плагин не всегда в описанной ситуации отработает, так как такая расширенная проектная модель не будет отображена в Visual Studio Extensibility API.
4) Так как проверка PVS-Studio интегрирована в сборочный процесс, то проект можно проверять (одновременно со сборкой) на системе без установленной IDE, например, на сборочном сервере во время ночной сборки.
Недостатки:
1) Поскольку запуск анализатора выполняет MSBuild, то получается, что он начинает отвечать за распараллеливание. MSBuild производит распараллеливание сборки на уровне проектов. Для каждого проекта запускается отдельный экземпляр MSBuild, а он в свою очередь запускает отдельный экземпляр PVS-Studio. Недостаток состоит в том, что нельзя выполнить параллельный анализ файлов в рамках одного проекта.
2) Интеграция с MSBuild приведёт к необходимости модификации проектного файла (*.vcxproj).