Статический анализ кода для проекта на meson

Лет ми гугл фор ю.

Не использовать убогий meson когда есть бесподобный Cmake.

бесподобный

Да уж, найти подобное дерьмо ещё та задача.

Ты в зеркало давно смотрел?

А это нормально, что автор зачастую предлагает использовать bash-скрипты вместо его всемогущей системы сборки?

Плюсы и минусы свои есть по сравнению с запуском custom target’а (думаю и в cmake и в meson можно это сделать). Например, в том же CI, если на все C++ проекты запускается один Pipeline (в разных конфигурациях), то баш портянки намного выгодней становятся, так как не надо проверять, написан ли данный таргет для данного проекта.

Не буду таким радикальным как оратор выше, но не считаю, что с современным cmake у разработчика возникнут много сложностей с системой сборки. Под современным cmake понимаю: presets, toolchain файлы, без глобальных состояний, с таргетами вместо libs + include path + whatever, нормальным package manager’ом: vcpkg/conan и нормальным хранилищем зависимостей (тот же artifactory). CMake в итоге победила все свои болячки без надобности в создании новой системы сборки (примерно как с плюсами и произошло).

P.S: С легкостью бы заменил vcpkg/conan + artifactory на nix + pkgconfig + nix hydra если бы не работал плотно с оффтопиком.
P.P.S: Из знакомых мне контор, которые пишут на плюсах, все перешли примерно на такой подход, что описал выше.

Меня в нем бесит его недоязык. И никакой «modern» его не спасает.

Это о clang-tidy или что-то другое?

Язык это конечно немного лишнее, его стоило бы еще сильнее урезать, не должна система сборки быть программируемым проектом.

Проблема в том, что в CMake язык не урезан. Это полноценный язык программирования, но с абсолютно идиотским синтаксисом и поведением типа «всё есть строка» или где неопределенную переменную можно молча раскрыть в пустоту. Последнее очевидно откуда растёт, это как раз случай когда скопировали самое худшее. Я когда-то давно тут писал комментарий про все недостатки языка CMake, но не имею привычки хранить ссылки на самого себя. :)

Что до «программируемости» – я согласен, но далеко не все вещи можно описать просто.

У меня долгого пути Ъ-программиста нет и поэтому мой скромный опыт говнокодерства говорит, что лучшее IDE то, что не тормозит. Поэтому для той же сишечки и крестов используется нетормозящий QtCreator. Тем более в нём с каждым релизом всё лучше поддержка человеческих инструментов, того же CMake, например.

У CMake много модулей. У CMake поддержка кучи компиляторов. CMake может сгенерить проектники под множество IDE. Я не знаю, есть ли такое у других, но именно это заставляет меня выбирать CMake снова и снова.

Какой это год? Мне аж интересно.

От любви до ненависти один шаг, не так ли?

Я бы назвал это опытом. %)

Вся эта поддержка IDE ничего не значит, когда нынче IDE (кстати, до сих пор пользуюсь QtCreator) можно скормить compile_commands.json и принципиально ничего не меняется.

Поддержка компиляторов бесполезна, когда ты всё равно ручками пишешь отдельно условия для msvc, отдельно для gcc. Если уж писать, то хотя бы на языке посерьёзнее. :)

Ещё ничего не значат модули, которые как оказалось в большинстве своём забагованы. Для тех же библиотек куда уж лучше полагаться на pkg-config.

По идее, да. cppcheck туда же.

Ещё интересно, чем можно заменить MISRA проверки, по типу тех, что есть в CLion.