Comments 85
Это замечательно. Ждем ебилды.
И со средами разными интеграцию сделали. Молодцы! Проделали огромную работу!
Да, хотелось бы ppa.
Кроме того, разработчики сабжа неоднократно подчёркивали, что не продают PVS-Studio частным лицам.
Поэтому, скорее всего, репозиторий у них будет свой.
Есть какой либо прогресс в этой области?
Думаю, что многим, как и мне интересен этот продукт, но смотреть на продукт, который тебе все равно не продадут — зачем?
Жаль, что рекламу на Хабре перестали даже маскировать под статьи. Могли бы хотя бы сравнение запилить с существующими до этого аналогами на линуксе. А то они бедные прозябали столько лет во тьме.
нет
Печально конечно, что на Хабре нельзя высказать свою точку зрения, если это не вылизывание причинного места. На ЛОРЕ линуксоиды уже высказали свое отношение. Но наверно это неправильные линуксоиды, и не для них предназначено.
А на ЛОРе на что угодно админы локалхоста пишут "не нужно". Вот это круто!
Причём здесь своё мнение? Я к сабжу прохладно отношусь, но какие-то статьи со сравнениями уже были. И разумеется в комментариях были недовольные методами сравнения. Прекрасно понимаю, что самому заморачиваться сравнением и писать статью может быть лень, но тогда забавно требовать это от других.
Тем более, что люди продолжали просить линукс-версию. В том числе, и на лоре, где контингент довольно специфический и на отдельных "ярких представителей" я бы равняться не стал.
Я пишу статьи на темы, которые мне интересны. С какой стати я должен помогать рекламировать их продукт, существование которого для меня безразлично? Я захожу почитать статьи на технические темы, которыми славится Хабр а не рекламу. И высказал свое недоумение по этому поводу.
на лоре, где контингент довольно специфический
Весь их контингент такой, начиная с Торвальдса. И именно этому контингенту предназначен продукт.
Зачем рекламировать? Разнеси их в пух и прах, если получится, конечно. Опять же, странно жаловаться на рекламу: они ведь в свой блог пишут — всё это так или иначе будет рекламой.
Не интересен продукт? Тогда что в этой теме делать вообще? Вроде, по первым строкам и, тем более, картинке должно быть понятно о чём речь пойдёт.
Весь их контингент такой, начиная с Торвальдса.
Ничего подобного. Во первых, "даже" на лоре есть вполне адекватные и не фанатичные люди. И если на то пошло, то я лор регулярно почитываю, как раз благодаря более живым комментариям. Впрочем, это палка о двух концах.
Во вторых, уверяю, что линуксом (как инструментом) пользуются совершенно разные люди. По совершенно разным причинам. Среди них есть и разработчики, которым может быть интересен сабж.
Бидапичаль. Рабочий проект прибит гвоздями к debian jessie i386, с кучей статических библиотек. Понятно, что x86 давно уже рудимент. Но менять десятки тысяч единиц оборудования никто не будет :-(
Кстати, а в чём сложность поддержки 32 бит? Уж вы то переносимый код писать умеете.
- Полный тестовый прогон это тяжкий процесс. Мы прогоняем PVS-Studio на 115 C++ открытых проектах и 50 C# открытых проектах. Все эти проекты прогоняются под Visual Studio 2010, 2012, 2013, 2015. Это много часов. Если надо прогнать ещё и 32-битную версию, это в 2 раза дольше. Плюс ещё под Linux теперь около 30 проектов.
- Собираемая статистика сказала нам, что количество запусков на Win32 системах меньше 4% (точное значение не помню). И дальше этот процент все равно будет только уменьшаться. А что касается клиентов, так вообще никого. Получается, что проблемы нет.
$ date +"%Y"
2016
И уж тем более машины разработчиков.
Я тут CLion с нетерпением ждал. А потом раз — и выпилили поддержку 32 бит.
Частично спасает lxc/docker, что бы элементарно иметь на машине свежие версии инструментов, от которых не зависит сборка (git, браузер, ssh и т.д.). Но IDE всё равно приходится запускать из окружения.
Нет. Просто у клиентов есть куча оборудования, которое не поддерживает 64 бита. Оборудование копилось годами, со своими функциями оно справляется на ура. Менять его поэтому никто не будет.
Ну вот смотрите. Нужен мне PVS-Studio для анализа проекта.
Проект имеет в зависимостях статическую библиотеку, исходников которой я не имею. Т.е. просто пересобрать под 64 бита у меня не выйдет, и пересобирать библиотеку мне никто не будет.
Выхода 3:
1) Сборка на таргет-системе. Но тогда я не смогу использовать PVS.
2) Кросс-компиляция. Придётся подготовить своими силами sysroot, своевременно следить за обновлениями. Большие костыли с запуском и отладкой.
3) Сборка с multilib. К сожалению, в debian multilib не для всех пакетов корректно реализован. При попытке установки 32-битных версий зависимостей, dpkg предлагает снести полсистемы из-за конфликтов, вплоть до DE.
Теперь у меня есть 64-битная машина. Как это мне поможет?
- Препроцессированные файлы — текстовые файлы.
- Получить их можно и нужно, запустив компилятор (вот где он нужен) с нужными параметрами.
- Правильная интеграция в сборочную систему позволяет правильно делать шаг, описанный выше.
- Смотреть на препроцессированные файлы пользователю обычно нет необходимости.
- Именно эти файлы являются исходными данными для анализа
Проект имеет в зависимостях статическую библиотеку, исходников которой я не имею. Т.е. просто пересобрать под 64 бита у меня не выйдет, и пересобирать библиотеку мне никто не будет.
Этапы линковки, что бы с ними не произошло, на анализ файлов не повлияют, но исходные файлы обязаны успешно компилиться.
Анализатор теперь только 64х битный, но анализировать он может любые компилируемые исходники, даже если компилятор 32х битный.
Я не спорю, это можно сделать. Но из нажатия одной кнопки запуск анализа превращается в целый квест.
Как-то так не сработает?
echo #!/usr/bin/ssh {x64host} > /usr/bin/pvs-studio
Ну и на {x64host} подмонтировать сетевую диру с исходниками :)
Способ интересный. Но pvs не через стандартный поток работает. Он вроде перехватывает системные вызовы, которые система сборки вызывает. А для этого его необходимо на той же машине запускать.
Но мне уже тут сказали, что линковка не влияет на анализ. Так что попробую запустить сборку на 64-битной машине.
Я последовал вашему совету. Запускал pvs через trace. Файлы компилируются успешно, но make прерывает сборку на этапе линковки. Лог-файл от pvs не создаётся.
Так же я пробовал интеграцию с qmake. Тоже никакой реакции.
Подскажите, лог создаётся после компиляции или во время?
Планируете ли добавить поддержку ObjC, Swift?
Планируете ли добавить поддержку других языков, скажем Java (судя по сайту C# вы поддерживаете)?
Для интеграции в QMake/CMake/QtCreator/CLion мы разработали 2 модуля. С большой вероятностью они позволят выполнить аналогичную интеграцию и в Windows. Я проверю такую возможность, но чуть позже.
Получил 11 бету, всё никак не соберусь просмотреть все предупреждения, но от того, что видел общее впечатление «PVS плохо работает с пользовательскими макросами».
Установка сейчас очень простая: распаковать, создать ~/.local-pvs, sed -r -i -e 's@^PREFIX=.*@PREFIX="$HOME/.local-pvs/bin"@' install.sh (зачем вообще кто‐то захардкодил там $PREFIX?), ./install.sh (можно с таким же успехом просто сделать cp имеющихся исполняемых файлов: скрипт просто зовёт install для копирования файлов с изменением пользователя/прав доступа, насколько я понимаю задачу install).
Использование тоже просто: с https://github.com/neovim/neovim
git clone https://github.com/neovim/neovim
cd neovim
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/root -DJEMALLOC_USE_BUNDLED=1
path=( ~/.local-pvs/bin $path ) # То же, что и изменение $PATH
rehash
pvs-studio-analyzer trace -- make
pvs-studio-analyzer analyze --lic-file /path/to/PVS-Studio.lic -o ../PVS-Studio.log
plog-converter -t errorfile -o ../PVS-Studio.log.conv ../PVS-Studio.log
# или
plog-converter -t xml -o ../PVS-Studio.log.xml ../PVS-Studio.logПервое выдаёт пригодные для того же Vim
/home/zyx/a.a/Proj/c/neovim/src/nvim/window.c:5138:1: error: V501 There are identical sub-expressions to the left and to the right of the '==' operator: (curtab) == curtab, второе
<message>
<trialMode>full</trialMode>
<stringNumber>5138</stringNumber>
<filePath>/home/zyx/a.a/Proj/c/neovim/src/nvim/window.c</filePath>
<errorType>error</errorType>
<errorCode>V501</errorCode>
<errorText>There are identical sub-expressions to the left and to the right of the '==' operator: (curtab) == curtab</errorText>
<isFalse>false</isFalse>
<errorLevel>1</errorLevel>
<prevString> int count = 0;</prevString>
<currentString> FOR_ALL_WINDOWS_IN_TAB(wp, curtab) {</currentString>
<nextString> if (wp->w_buffer != NULL</nextString>
<extendedString></extendedString>
</message>. И это, как раз, пример сообщения об «ошибке» в макросах. Впрочем, из XML файла их легко убрать, просто не доходят руки написать фильтр. Ошибок PVS тоже немало нашёл, но шума от макросов куда больше.
На ЛОРе пользователи в двух темах написали, что ваша студия статически линкуется с GPL кодом
http://www.linux.org.ru/news/proprietary/12967863/page4
http://www.linux.org.ru/forum/development/12896582/page2
Андрей Карпов живо откликается на многие вопросы, но на эти почему то не нашел времени ответить. Интересно было бы услышать комментарии
Linux-версия PVS-Studio не смогла обойти стороной CodeLite
Обращение ко всем пользователям Linux-версии PVS-Studio 6.10.
WARNING! Хочу обратить внимание, что сырой лог, полученный сразу после проверки использовать нельзя! Он не предназначен для просмотра и служит только как источник данных для программы plog-converter.
К нам стало приходить большое количество писем, что результатами работы PVS-Studio пользоваться невозможно. Программисты получают огромный файл, с тысячами одинаковых сообщений на один заголовочный *.h файл и прочим мусором. Мучаются, жалуются. Другие, наверное, не жалуются, а молча теряют интерес к PVS-Studio.
Эти файлы и не предназначены для просмотра. Для преобразования их в «человеческий» формат служит утилита plog-converter, описанная в документации. Эта утилита не только преобразует лог, но и удаляет в нём дубликаты для h-файлов, фильтрует сообщения и так далее. Например, есть смысл начать изучение отчета с предупреждений общего назначения первого и второго уровня (ключ -a GA:1,2). Это очень важно, так как иначе программист просто утонет в сообщениях.
В следующей версии, мы планируем изменить изначального формат лога, чтобы было понятно, что это некий бинарный формат и он не предназначен для просмотра. Это должно подсказать программисту, что с этим файлом надо ещё что-то сделать и он, продолжив в чтение документации, будет узнавать про plog-converter.
PVS-Studio для Linux