Исправление SZT, (текущая версия) :
Ей как минимум надо передать информацию, что за компилятор используется. Это в стандарте C/C++ однороден. На практике это диалекты и надо знать какой именно
GCC/Clang для языка Си понимает -std=c89, c90 c99, c11, gnu90 gnu99 gnu11 и еще кучу для всяких плюсовых версий стандарта... это все передается при сборке через флаги. Не вижу никакой проблемы с передачей информации о том, какой именно компилятор используется и с каким стандартом компилируется код
А ещё есть важные дополнительные настройки.
А их никак нельзя задать через флаги?
И на практике не так просто бывает всё это подменить и передать в системе сборки. Вот уже есть неудобства.
Ну вот давайте конкретные сложности на практике опишите, что там неудобно может быть? Вместо вызова настоящего компилятора вызываем некий псевдокомпилятор, который выдает вместо объектных файлов псевдообъектные pvs-studio файлы, и на этапе какбы-линковки потом эти псевдообъектные файлы полностью анализируются в общем и целом. Где на практике возникнут проблемы?
Выплюнуть текстовый файл - какой-то каменный век. Надо что-то куда-то прикручивать самому.
Я считаю что когда софт намертво прикручен к ОДНОЙ КОНКРЕТНОЙ IDE работающей полноценно только в ОС семействах Windows - какой-то каменный век. Посмотрите например на список поддеживаемых к GDB фронт-энтов https://sourceware.org/gdb/wiki/GDB Front Ends
Как так получилось? У GDB есть некий открытый и документированный интерфейс https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html для взаимодействия отладчика со средой разработки. У вас же ничего подобного нет. Написали все эти фронт-энды к GDB отнюдь не сами разработчики GDB. Разработчики просто предоставили некий способ прикрутить этот GDB к чему вздумается, и этим воспользовались другие.
И не понятно, как сделать интерактивный доступ к help (описанию диагностик).
Это (вопрос интеграции с конкретной средой разработки, когда кто-то мышкой кликает на «диагностика №1234» - ему выскакивает описание, что эта диагностика означает) должно решаться теми, кто решит прикручивать все это к какой-то среде разработки(будь то Qt creator, eclipse или что там еще...). Просто нужна некая БД со списком ошибок, и возможность из этой БД по номеру ошибки получить текст описания ошибки, дальше уже как-нибудь сами без вас разберутся.
Про гибкую динамическую настройку фильтров я вообще молчу.
А что там за такая динамическая настройка фильтров, которую нельзя реализовать какими-нибудь регулярками? Можно всю базу с предупреждениями засунуть в какую-нибудь СУБД и потом оттуда что-то фильтровать, просматривать предупреждения только какого-то уровня и прочее, прочее, но это не надо заталкивать в саму систему для провеки исходного кода. UNIX-way. Достаточно выплюнуть в текстовом виде все предупреждения, и потом пусть уже пользователь сам делает какие-то выборки из них любым удобным ему способом, заталкивает это все в БД, или через grep какой-нибудь. Как угодно.
Итого, в результате получится полудикая неудобная утилита.
Вы похоже просто живете в каком-то параллельном мире, где удобно это когда утилита прибита гвоздями к какой-то одной конкретной неудобной(для многих пользователей GNU/Linux) кривой IDE и работает только в виндах.
А как-же IncrediBuild... Всё остаётся мимо...
distcc в помошь
Исходная версия SZT, :
Ей как минимум надо передать информацию, что за компилятор используется. Это в стандарте C/C++ однороден. На практике это диалекты и надо знать какой именно
GCC/Clang для языка Си понимает -std=c89, c90 c99, c11, gnu90 gnu99 gnu11 и еще кучу для всяких плюсовых версий стандарта... это все передается при сборке через флаги. Не вижу никакой проблемы с передачей информации о том, какой именно компилятор используется и с каким стандартом компилируется код
А ещё есть важные дополнительные настройки.
А их никак нельзя задать через флаги?
И на практике не так просто бывает всё это подменить и передать в системе сборки. Вот уже есть неудобства.
Ну вот давайте конкретные сложности на практике опишите, что там неудобно может быть? Вместо вызова настоящего компилятора вызываем некий псевдокомпилятор, который выдает вместо объектных файлов псевдообъектные pvs-studio файлы, и на этапе какбы-линковки потом эти псевдообъектные файлы полностью анализируются в общем и целом. Где на практике возникнут проблемы?
Выплюнуть текстовый файл - какой-то каменный век. Надо что-то куда-то прикручивать самому.
Я считаю что когда софт намертво прикручен к ОДНОЙ КОНКРЕТНОЙ IDE работающей полноценно только в ОС семействах Windows - какой-то каменный век. Посмотрите например на список поддеживаемых к GDB фронт-энтов https://sourceware.org/gdb/wiki/GDB Front Ends
Как так получилось? У GDB есть некий открытый и документированный интерфейс для взаимодействия отладчика со средой разработки. У вас же ничего подобного нет. Написали все эти фронт-энды к GDB отнюдь не сами разработчики GDB. Разработчики просто предоставили некий способ прикрутить этот GDB к чему вздумается, и этим воспользовались другие.
И не понятно, как сделать интерактивный доступ к help (описанию диагностик).
Это (вопрос интеграции с конкретной средой разработки, когда кто-то мышкой кликает на «диагностика №1234» - ему выскакивает описание, что эта диагностика означает) должно решаться теми, кто решит прикручивать все это к какой-то среде разработки(будь то Qt creator, eclipse или что там еще...). Просто нужна некая БД со списком ошибок, и возможность из этой БД по номеру ошибки получить текст описания ошибки, дальше уже как-нибудь сами без вас разберутся.
Про гибкую динамическую настройку фильтров я вообще молчу.
А что там за такая динамическая настройка фильтров, которую нельзя реализовать какими-нибудь регулярками? Можно всю базу с предупреждениями засунуть в какую-нибудь СУБД и потом оттуда что-то фильтровать, просматривать предупреждения только какого-то уровня и прочее, прочее, но это не надо заталкивать в саму систему для провеки исходного кода. UNIX-way. Достаточно выплюнуть в текстовом виде все предупреждения, и потом пусть уже пользователь сам делает какие-то выборки из них любым удобным ему способом, заталкивает это все в БД, или через grep какой-нибудь. Как угодно.
Итого, в результате получится полудикая неудобная утилита.
Вы похоже просто живете в каком-то параллельном мире, где удобно это когда утилита прибита гвоздями к какой-то одной конкретной неудобной(для многих пользователей GNU/Linux) кривой IDE и работает только в виндах.
А как-же IncrediBuild... Всё остаётся мимо...
distcc в помошь