# PVS\-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор\. Легко и "из коробки"

Сейчас в PVS\-Studio мы делаем бомбу\! 

![0243_CLMonitoring_ru/image1.png](https://import.viva64.com/docx/blog/0243_CLMonitoring_ru/image1.png)

В следующей версии PVS\-Studio 5\.15 сможет проверять проекты, которые собираются абсолютно в любой сборочной системе: Makefile, Visual Studio Project, собственная система сборки на основе Python, Bash или что там еще\.\.\. Теперь мы можем просто "наблюдать" за вызовами компилятора\. И собирать всю необходимую информацию для запуска анализа автоматически\. Более того, это работает с любым \(разумным\) компилятором C/C\+\+, который запускается в Windows\. Хотите подробностей?

## Как работает плагин к Visual Studio и почему это ограничивало возможность использования?

Изначально PVS\-Studio это плагин для Microsoft Visual C\+\+\. Взаимодействие со средой разработки заключается в двух аспектах\. Во\-первых, это интеграция в пользовательский интерфейс\. Ведь удобно работать с инструментом из привычной среды\. Во\-вторых, это получения параметров компиляции файлов для того, чтобы провести правильный анализ\.

Для тех, кто не очень знаком с механизмом работы анализаторов кода \(и в частности PVS\-Studio\), я напомню\. Прежде, чем выполнять анализ, необходимо выполнить препроцессирование, т\.е\. раскрыть все \#include и \#define\. Это делается для того, чтобы узнать дополнительную информацию об используемых типах данных прежде всего\.

Плагин PVS\-Studio собирал параметры компиляции с использованием API среды Visual Studio и запускал препроцессирование самостоятельно\. Теперь мы научились следить за тем, с какими параметрами запускается компилятор и "повторять" его вызов с ключом "выполнить препроцессирование"\. А затем уже запускать анализатор\. Это ничего не меняет для плагина, в нем так и остается старый механизм\. Но для некоторых проектов \(даже для некоторых родных проектов Visual C\+\+\) этот механизм не мог быть использован\. О каких случаях идет речь?

Во\-первых, если у вас Makefile\-проект, который собирается, например, с помощью nmake\. Тогда API среды Visual Studio не позволяло узнать плагину параметры компиляции и вызвать препроцессированние\. Конечно, вы всегда могли [встроить](https://pvs-studio.ru/ru/docs/manual/0006/) вызов PVS\-Studio в Makefile\. Но, будем честны, это не самое удобное решение, которое можно предложить\. Нет, конечно у нас есть пользователи, которые используют PVS\-Studio именно так\. Но многих такой сценарий отпугивал\.

Во\-вторых, если у вас самописная система сборки, которая вызывает компилятор из скриптов, то это хоть и похоже на Makefile, то только в теории\. На практике модифицировать такую систему сборки может часто только ее автор, который может быть не доступен\. И попробовать PVS\-Studio на таком проекте оказывается почти невозможно\.

Другими словами, нередко возникали ситуации, что вроде и проект собирается компилятором Visual C\+\+, и есть желание попробовать PVS\-Studio\. Но это оказывалось не очень легко и желание плавно сходило на нет\.\.\.

## Как мы решили эту проблему?

Мы разработали специальную утилиту мониторинга вызова компиляторов\. Она работает с основными компиляторами для Windows, но, как и прежде, наш главный фокус: пользователи Visual C\+\+\.

Инструмент для мониторинга просто перехватывает все вызовы компилятора и затем запускает компилятор еще раз с параметров "препроцессировать файл", после чего уже вызывает анализатор\. Главная прелесть в том, что все это делается абсолютно прозрачно для пользователя и повторить это может любой\.

Причем мы предоставляем два разных способа воспользоваться этой возможностью\.

## Вариант 1 – Мониторинг с графическим интерфейсом

Итак, предположим вы получили доступ к исходникам [Unreal Engine 4](https://www.unrealengine.com/en-us/)\. Вы открываете солюшен в Visual Studio и видите, что это nmake\-based проект, поэтому проверить его с помощью плагина PVS\-Studio нельзя\. Это не проблема\. Вы делаете следующее:

1. Запускаете PVS\-Studio Standalone\.
1. Нажимаете кнопку "Compiler Monitoring", где выбираете платформу x64 для мониторинга\. Ведь в Unreal Engine 4 вы будете собирать 64\-битную версию\.
1. Нажав на кнопку "Start Monitoring" вы увидите, что включился режим наблюдения за вызовами компилятора\.
1. Теперь вы идете в Visual Studio и нажимаете кнопку Build – пошла сборка проекта\. При этом в окне мониторинга вы видите, что перехватываются вызовы компилятора\. Обратите внимание, что там пишется количество перехваченных вызов, а не количество файлов с кодом\. Дело в том, что часто компилятор запускается с несколькими файлами в аргументах\. Поэтому количество запусков компилятора меньше или равно количеству файлов\.
1. Когда сборка в Visual Studio закончилась, вы нажимаете кнопку Stop Monitoring\. И тогда начинается работа PVS\-Studio\. Файлы препроцессируются и анализируются\. Диагностические сообщения появляются в окне утилиты PVS\-Studio Standalone\. Вы можете сразу начать с ними работать\. Но я рекомендую дождаться завершения анализа, сохранить полученный результат проверки в файл UE4\.plog\. Затем закрыть PVS\-Studio Standalone, открыть файл UE4\.plog из среды Visual Studio с помощью меню PVS\-Studio и работать с результатами проверки уже там\. Почему? Да потому что в среде Visual Studio у вас будет IntelliSense, и вы сможете легко делать навигацию по коду, смотреть значения макросов, искать объявления переменных\. Все это конечно можно делать и в PVS\-Studio Standalone, но будем честны – до Visual Studio нашему инструменту далеко по удобству использованию\.

Таким простым способом вы можете проверять проекты, используя графический интерфейс мониторинга в PVS\-Studio\. Но ведь бывает удобно еще и из командной строки запускать мониторинг? Об этом в следующем разделе\.

## Вариант 2 – Мониторинг с интерфейсом командной строки

Но бывает и так, что графический интерфейс для мониторинга не очень удобен\. Предположим, мы хотим проверить [Qt 5\.2](https://www.qt.io/developers)\. Для этого мы скачиваем дистрибутив в виде архива, распаковываем его\. Запускаем Visual Studio 2012 Command Promt \(для правильного окружения\), переходим в папку с Qt и делаем следующее:

1. Запускаем режим мониторинга: "C:\\Program Files \(x86\)\\PVS\-Studio\\CLMonitor\.exe" monitor Программа сразу завершится, но оставит "следящий модуль" в памяти\.
1. Запускаем configure\.exe – это программа из пакета Qt, которая подготавливает скрипт для сборки\.
1. Запускаем nmake – откиньтесь на спинку кресла и подождите, пока Qt соберется\.
1. Когда сборка Qt завершилась, то надо сказать мониторингу, что пора закончить следить и начать делать анализ \(для платформы Win32, результаты сохранить в log\): "C:\\Program Files \(x86\)\\PVS\-Studio\\CLMonitor\.exe" analyze C:\\Qt5\.plog Win32
1. Когда анализ будет завершен, результат работы анализатора будет сохранен в plog\-файле\. Я не рекомендую работать с логом напрямую\. Лучше открыть его в PVS\-Studio Standalone, там работать с логом намного удобнее\.

Как видно, проверять проекты с любой системой сборки из командной строки ничуть не сложнее, чем при использовании пользовательского интерфейса\. Те же 5 простых пунктов\.

## О проблемах и ограничениях

Каких\-либо принципиальных проблем в технологии мониторинга мы \(пока?\) не выявили\. Но о некоторых нюансах стоит все\-таки знать\.

Во\-первых, мониторинг перехватывает все вызовы компилятора\.  А это значит, что если вы запустите несколько разных процессов на сборку, то перехвачены будут все\. И проанализированы\. То есть в результатах проверки будет каша из правильного и "чужого" проекта\. Не забывайте об этом и не запускайте никакие другие процессы сборки во время работы мониторинга\.

Во\-вторых, иногда бывают нюансы с precompiled headers\. Нередко бывает так, что путь до прекомпилированных заголовков отсутствует в списке include\-папок\. При этом компилятор находит такие заголовки, а препроцессор \(являющийся часть компилятора\!\) – уже не находит\. Здесь решение простое – добавить явно путь до некоторых включаемых файлов с список include\-папок\.

## Trial Mode

Теперь небольшая ложка дегтя\. В PVS\-Studio есть триальный режим, который ограничивает клики в списке обнаруженных проблем\. Однако при использовании PVS\-Studio из командной строки и в режиме мониторинга имена файлов совсем не показываются\. Вместо этого выдаются сообщения "Trial Restriction"\. Но вы всё же можете познакомиться как работает режим мониторинга и на триале, используя UI приложение PVS\-Studio Standalone \(пункт меню Tools \-\> Analyze your files\.\.\.\)\.