Сейчас в PVS-Studio мы делаем бомбу!
В следующей версии 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 не позволяло узнать плагину параметры компиляции и вызвать препроцессированние. Конечно, вы всегда могли встроить вызов PVS-Studio в Makefile. Но, будем честны, это не самое удобное решение, которое можно предложить. Нет, конечно у нас есть пользователи, которые используют PVS-Studio именно так. Но многих такой сценарий отпугивал.
Во-вторых, если у вас самописная система сборки, которая вызывает компилятор из скриптов, то это хоть и похоже на Makefile, то только в теории. На практике модифицировать такую систему сборки может часто только ее автор, который может быть не доступен. И попробовать PVS-Studio на таком проекте оказывается почти невозможно.
Другими словами, нередко возникали ситуации, что вроде и проект собирается компилятором Visual C++, и есть желание попробовать PVS-Studio. Но это оказывалось не очень легко и желание плавно сходило на нет…
Как мы решили эту проблему?
Мы разработали специальную утилиту мониторинга вызова компиляторов. Она работает с основными компиляторами для Windows, но, как и прежде, наш главный фокус: пользователи Visual C++.
Инструмент для мониторинга просто перехватывает все вызовы компилятора и затем запускает компилятор еще раз с параметров «препроцессировать файл», после чего уже вызывает анализатор. Главная прелесть в том, что все это делается абсолютно прозрачно для пользователя и повторить это может любой.
Причем мы предоставляем два разных способа воспользоваться этой возможностью.
Вариант 1 – Мониторинг с графическим интерфейсом
Итак, предположим вы получили доступ к исходникам Unreal Engine 4. Вы открываете солюшен в Visual Studio и видите, что это nmake-based проект, поэтому проверить его с помощью плагина PVS-Studio нельзя. Это не проблема. Вы делаете следующее:
- Запускаете PVS-Studio Standalone.
- Нажимаете кнопку «Compiler Monitoring», где выбираете платформу x64 для мониторинга. Ведь в Unreal Engine 4 вы будете собирать 64-битную версию.
- Нажав на кнопку «Start Monitoring» вы увидите, что включился режим наблюдения за вызовами компилятора.
- Теперь вы идете в Visual Studio и нажимаете кнопку Build – пошла сборка проекта. При этом в окне мониторинга вы видите, что перехватываются вызовы компилятора. Обратите внимание, что там пишется количество перехваченных вызов, а не количество файлов с кодом. Дело в том, что часто компилятор запускается с несколькими файлами в аргументах. Поэтому количество запусков компилятора меньше или равно количеству файлов.
- Когда сборка в 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 нашему инструменту далеко по удобству использованию.
Вариант 2 – Мониторинг с интерфейсом командной строки
Но бывает и так, что графический интерфейс для мониторинга не очень удобен. Предположим, мы хотим проверить Qt 5.2. Для этого мы скачиваем дистрибутив в виде архива, распаковываем его. Запускаем Visual Studio 2012 Command Promt (для правильного окружения), переходим в папку с Qt и делаем следующее:
- Запускаем режим мониторинга:
Программа сразу завершится, но оставит «следящий модуль» в памяти.
- Запускаем configure.exe – это программа из пакета Qt, которая подготавливает скрипт для сборки.
- Запускаем nmake – откиньтесь на спинку кресла и подождите, пока Qt соберется.
- Когда сборка Qt завершилась, то надо сказать мониторингу, что пора закончить следить и начать делать анализ (для платформы Win32, результаты сохранить в log):
- Когда анализ будет завершен, результат работы анализатора будет сохранен в log-файле. Я не рекомендую работать с логом напрямую. Лучше открыть его в PVS-Studio Standalone, там работать с логом намного удобнее.
О проблемах и ограничениях
Каких-либо принципиальных проблем в технологии мониторинга мы (пока?) не выявили. Но о некоторых нюансах стоит все-таки знать.
Во-первых, мониторинг перехватывает все вызовы компилятора. А это значит, что если вы запустите несколько разных процессов на сборку, то перехвачены будут все. И проанализированы. То есть в результатах проверки будет каша из правильного и «чужого» проекта. Не забывайте об этом и не запускайте никакие другие процессы сборки во время работы мониторинга.
Во-вторых, иногда бывают нюансы с precompiled headers. Нередко бывает так, что путь до прекомпилированных заголовков отсутствует в списке include-папок. При этом компилятор находит такие заголовки, а препроцессор (являющийся часть компилятора!) – уже не находит. Здесь решение простое – добавить явно путь до некоторых включаемых файлов с список include-папок.
Trial Mode
Теперь небольшая ложка дегтя. В PVS-Studio есть триальный режим, который ограничивает клики в списке обнаруженных проблем. Однако при использовании PVS-Studio из командной строки и в режиме мониторинга имена файлов совсем не показываются. Вместо этого выдаются сообщения «Trial Restriction». Мы знаем об этой особенности, пока она не устранена. Вы можете познакомиться как работает в принципе режим мониторинга и на триале. А оценить диагностические возможности анализатора можно на обычных проектах Visual Studio. Если все-таки этого не достаточно и хочется попробовать мониторинг компиляции в деле, а у вас нет лицензии, то напишите нам – дадим временный ключ.
