Опыт мигрирования крупного проекта с Windows-only на Linux

1. Опыт портирования
Windows-only проекта
на Linux
ПАВЕЛ БЕЛИКОВ
PVS-STUDIO

2. Проблемы портирования
• Миф о стандартном C++
• Мало перенести ядро анализатора
• Необходимы инструменты для проверки проекта
• Необходимы средства просмотра отчёта

3. Системы сборки
Windows: MSBuild
Linux:
• CMake
• qmake
• qbs
• autotools
• waf
• Scons
• GYP
• bazel
• Не поддающееся подсчёту множество скриптов и Makefile

4. Мониторинг сборки
• Переменные окружения CC, CXX (пример: scan-build)
• strace

5. JSON Compilation Database
• Описание всех команд компиляции в проекте
• Не нужно пересобирать приложение
[
{ "directory": "/home/user/projects/test",
"command": "/usr/bin/c++ file.cpp",
"file": "file.cpp" },
...
]

6. Bear
• Использует LD_PRELOAD
• Не собирает информацию о переменных окружения
• Проблемы дистрибуции (разные версии glibc)

7. Почему нельзя проверять исходники?
• Нельзя получить информацию о типах, а следовательно и провести статический анализ
• Статический анализ по регуляркам не статический анализ
• C++ парсер без знания типов написать невозможно
Но если очень хочется, то можно:
pvs-studio-analyzer trace -- g++ *.cpp -o dummy
pvs-studio-analyzer analyze ...
plog-converter ...

8. Система тестирования
• 34 новых (и не очень) проектов под Linux
• За основу взят мониторинг сборки deb-пакетов через apt
• 120 + 34 > 120
• Больше C
• Больше современного C++
• Больше шаблонов

9. Система тестирования

10. Документация
• Любой продукт должен содержать документацию
• Она должна быть удобной
• Но читают её не все

11. Дистрибуция
• Архив исключительно на крайний случай – он неудобен
• Нужны deb и rpm, желательно с репозиториями
• Нужно работать на огромном зоопарке дистрибутивов
• И всё это нужно тестировать

12. Интерфейс
• Текстовый конфигурационный файл – это конечно Unix-way
• Но без CLI неудобно

13. Методология статического анализа
• Анализатор – инструмент разработчика
• Использовать его только в CI нельзя

14. Интеграция в IDE
• IDE у каждого своё: от Unix as IDE до CLion
• Плагины ко всему писать невозможно
• Время обратиться к Unix-way: проще всего интегрироваться в систему сборки
• Плюс: поддерживается инкрементальный анализ и (почти) любая IDE
• Минус: интегрироваться сложно
• Для CMake и qmake мы написали модули для облегчения интеграции

15. QtCreator + qmake

16. CLion + CMake

17. Vim в качестве просмотрщика лога

18. Просматривать логи можно и в
QtCreator
plog-converter -t tasklist -o PVS-Studio.tasks PVS-Studio.log
Tasks – формат QtCreator для удобной загрузки сообщений в окно Issues.

19. Что дальше?
• Вроде всё готово?
• Нееееееееет.
• Осталось море работы по поддержке GCC и Clang
• Расширения компиляторов
• Уменьшение количества ложных срабатываний

20. Расширения GCC
int *p = x ? : y; switch (x) {
case 0 ... 50: return 0;
default: return 1;
};
void *l = &&label;
goto *l;
И многое другое, не всегда документированное
#define min(a,b) = ({
typeof(a) _a = a;
typeof(b) _b = b;
a > _b ? _a : _b;
)}

21. Что у нас получилось
• Работать на разных дистрибутивах
• Устанавливаться из пакетов (и даже репозиториев)
• Сделать инструменты для быстрой проверки
• Сделать инструменты для интеграции в билд-сервер
• Сделать инструменты для программиста
А ещё мы проверили много проектов, включая ядро Linux. Скоро будет статья!

22. Готов ответить на ваши вопросы
Наш сайт: www.viva64.com
Блог на хабре: https://habrahabr.ru/company/pvs-studio/