Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
Сейчас в PVS-Studio мы делаем бомбу!
В следующей версии PVS-Studio 5.15 сможет проверять проекты, которые собираются абсолютно в любой сборочной системе: Makefile, Visual Studio Project, собственная система сборки на основе Python, Bash или что там еще... Теперь мы можем просто "наблюдать" за вызовами компилятора. И собирать всю необходимую информацию для запуска анализа автоматически. Более того, это работает с любым (разумным) компилятором C/C++, который запускается в Windows. Хотите подробностей?
Изначально 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++.
Инструмент для мониторинга просто перехватывает все вызовы компилятора и затем запускает компилятор еще раз с параметров "препроцессировать файл", после чего уже вызывает анализатор. Главная прелесть в том, что все это делается абсолютно прозрачно для пользователя и повторить это может любой.
Причем мы предоставляем два разных способа воспользоваться этой возможностью.
Итак, предположим вы получили доступ к исходникам Unreal Engine 4. Вы открываете солюшен в Visual Studio и видите, что это nmake-based проект, поэтому проверить его с помощью плагина PVS-Studio нельзя. Это не проблема. Вы делаете следующее:
Таким простым способом вы можете проверять проекты, используя графический интерфейс мониторинга в PVS-Studio. Но ведь бывает удобно еще и из командной строки запускать мониторинг? Об этом в следующем разделе.
Но бывает и так, что графический интерфейс для мониторинга не очень удобен. Предположим, мы хотим проверить Qt 5.2. Для этого мы скачиваем дистрибутив в виде архива, распаковываем его. Запускаем Visual Studio 2012 Command Promt (для правильного окружения), переходим в папку с Qt и делаем следующее:
Как видно, проверять проекты с любой системой сборки из командной строки ничуть не сложнее, чем при использовании пользовательского интерфейса. Те же 5 простых пунктов.
Каких-либо принципиальных проблем в технологии мониторинга мы (пока?) не выявили. Но о некоторых нюансах стоит все-таки знать.
Во-первых, мониторинг перехватывает все вызовы компилятора. А это значит, что если вы запустите несколько разных процессов на сборку, то перехвачены будут все. И проанализированы. То есть в результатах проверки будет каша из правильного и "чужого" проекта. Не забывайте об этом и не запускайте никакие другие процессы сборки во время работы мониторинга.
Во-вторых, иногда бывают нюансы с precompiled headers. Нередко бывает так, что путь до прекомпилированных заголовков отсутствует в списке include-папок. При этом компилятор находит такие заголовки, а препроцессор (являющийся часть компилятора!) – уже не находит. Здесь решение простое – добавить явно путь до некоторых включаемых файлов с список include-папок.
Теперь небольшая ложка дегтя. В PVS-Studio есть триальный режим, который ограничивает клики в списке обнаруженных проблем. Однако при использовании PVS-Studio из командной строки и в режиме мониторинга имена файлов совсем не показываются. Вместо этого выдаются сообщения "Trial Restriction". Но вы всё же можете познакомиться как работает режим мониторинга и на триале, используя UI приложение PVS-Studio Standalone (пункт меню Tools -> Analyze your files...).
0
0
0
0