# Встраиваем PVS\-Studio в Eclipse CDT \(Linux\)

Новость о возможности бесплатной проверки исходников с помощью PVS\-Studio наконец\-то простимулировала меня внедрить проверку исходников в Eclipse CDT\. А то для CLion/QtCreator/etc написано как, а фиолетовых обошли :\) Для экспериментов использовались: Eclipse IDE for C/C\+\+ Developers, Version: Neon\.1a Release \(4\.6\.1\), Build id: 20161007\-1200 и PVS\-Studio 6\.11\.20138\.1\. И вот что получилось\.


> Статья впервые была \[опубликована\]\(https://habr\.com/ru/post/316670/\) на русском языке на сайте habrahabr\\\.ru\\\. Статья и её перевод размещаются на нашем сайте с согласия автора\\\.

Для начала обернём вызов анализатора в скрипт \(о нём позже\) и будем вызывать его как внешнюю утилиту\. В конфигурации укажем рабочий каталог:

![0458_Eclipse_CDT_ru/image2.png](https://import.viva64.com/docx/blog/0458_Eclipse_CDT_ru/image2.png)

_Рисунок 1 \- External Tools Configurations / Main_

И включим галочку "Allocate console":

![0458_Eclipse_CDT_ru/image4.png](https://import.viva64.com/docx/blog/0458_Eclipse_CDT_ru/image4.png)

_Рисунок 2 \- External Tools Configurations / Main_

Недостаток этого способа в том, что вывод не будет разбираться эклипсовским парсером, и его можно будет увидеть только в консоли:

![0458_Eclipse_CDT_ru/image6.png](https://import.viva64.com/docx/blog/0458_Eclipse_CDT_ru/image6.png)

_Рисунок 3 \- Run as External Tool_

Если такой способ не устраивает, можно встроить проверку во внешнюю утилиту для сборки\. Способ годится не для всех проектов, но если он устраивает, то идём в свойства проекта и настраиваем параметры External Builder для текущей конфигурации:

1. Выбираем External builder в качестве Build type
1. Снимаем галочку с "Use default build command"
1. В поле "Build command" вводим наш скрипт
1. Отмечаем "Generate Makefiles automatically"

![0458_Eclipse_CDT_ru/image8.png](https://import.viva64.com/docx/blog/0458_Eclipse_CDT_ru/image8.png)

_Рисунок 4 \- C/C\+\+ Build_

Ключ "\-k" Eclipse добавляет сам\. Соответственно, при построении проекта наш скрипт будет вызван с ключами "\-k all", при очистке — с "\-k clean"\.

В итоге мы получим автоматическую проверку проекта при сборке, плюс вывод, который разбирается Eclipse и, как следствие, навигацию по исходникам в окне "Problems":

![0458_Eclipse_CDT_ru/image10.png](https://import.viva64.com/docx/blog/0458_Eclipse_CDT_ru/image10.png)

_Рисунок 5 \- Run as Builder_

Ну а теперь сам скрипт:

```cpp
#!/bin/sh

# без аргументов скрипт вызывается как External Tool,
# принудительно вызываем 'make clean':
if [ -z "$1" ]; then
    make -f makefile clean
fi

# вызов из билдера, проверяем цели:
if [ "$2" = "clean" ]; then
    make -f makefile clean
   # здесь больше ничего делать не надо:
    exit
fi

# не clean или вызвали как External Tool - анализируем проект:
TEMPLOG=$(tempfile)

# удаляем ошмётки 'strace', которые могут появиться 
# в некоторых случаях:
pvs-studio-analyzer trace -- make -f makefile all 2>&1 \
    | sed '/strace: umovestr:/d' -
pvs-studio-analyzer analyze -o "$TEMPLOG"

# удаляем непонятную строку, которая у меня появляется 
# в выводе конвертера:
RC=$(plog-converter -t errorfile "$TEMPLOG" \
    | sed '/The documentation for all/d' -)
rm -f "$TEMPLOG"
echo "$RC"
```

Пока всё\. На реальных проектах ещё ничего не гонялось, может там и вылезут какие\-то недоделки\. Но общая схема в принципе понятна\.