CMake: тот случай, когда проекту непростительно качество его кода

[mapron]

Имел «удовольствие» попробовать сделать некоторые доработки в кодовую базу CMake. К сожалению, там не только по коду статический анализ плачет — высокая связность компонентов приводит к тому, что почти невозможно правки делать только в одном месте. После работы с сорцами QBS я реально плакал, кусал локти и матерился(
Если у кого-то был положительный опыт работы с исходниками CMake — поделитесь им, пожалуйста.
По поводу «как тут с разыменованием нулевого указателя не падает» — у меня субъективно сложилось ощущение во время отладки, что там по большей части условий управление не ходит вообще. Т.е. смотришь на условие и не можешь найти способ чтобы оно выполнялось (опять же не берусь утверждать что там есть мертвый код). В общем, с таким неочевидным потоком выполнения кода там крайне легко допускать такие ляпы.

Надеюсь кто-то из разрабов CMake станет пользоваться PVS :)

[Antervis]

После работы с сорцами QBS я реально плакал, кусал локти и матерился(
Если у кого-то был положительный опыт работы с исходниками CMake — поделитесь им, пожалуйста

тем временем QBS задепрекейтили в пользу CMake. Боль, тоска, печаль

[mapron]

QBS как таковой не задепрекейтили. Задепрекетили использование QBS в качестве сборочной системы Qt и ее продвижение в Qt Creator. Выпиливать ее поддержку не будут, конечно, т.е. особых рисков использовать ее для своих проектов дальше — нет.

(ну и опять же «работать с исходниками» != «работать с самой сборочной системой»).
Как пользователь CMake я ей вполне доволен, и считаю что переход на CMake для Qt (как было с KDE) — решение хотя и спорное, но в целом взвешенное и даст определенные преимущества.

[Antervis]

QBS как таковой не задепрекейтили

судя по посту в официальном блоге задепрекейтили именно QBS как таковой. А сборку Qt/QtCreator'а на QBS так и не перевели, чтобы депрекейтить.

[apro]

тем временем QBS задепрекейтили в пользу CMake. Боль, тоска, печаль

Ну не так уж все плохо, в результате этого перехода разработчики Qt наконец-то запили в cmake официальную поддержку pch: https://gitlab.kitware.com/cmake/cmake/merge_requests/3553

Так что я думаю часть возможностей qmake/qbs перекочует в cmake.

[gudvinr]

часть возможностей qmake/qbs перекочует в cmake

Самой ценной возможность QBS был нормальный понятный C-подобный синтаксис и весьма удобная декларативная разметка, а не дичайшее лиспоподобное нечто. Именно возможностей у CMake завались, проблема у него совсем не в этом.

[slonopotamus]

После работы с сорцами QBS я реально плакал, кусал локти и матерился

Так CMake или QBS? Насколько мне известно, это два абсолютно независимых друг от друга программы.

[mapron]

Я плохо выразился — после работы с сорцами QBS, в сравнении с ними, работа с CMake — далее по тексту.
Прошу прощения за неоднозначность)

[podsvirov]

К вопросу о положительном опыте работы с исходниками CMake. У меня есть такой, как я считаю, положительный опыт.
Я разработал и внедрил CPack IFW Generator, который был добавлен в версии 3.1.
Также я добавил поддержку опции проекта CMake_BUILD_DEVELOPER_REFERENCE, которая позволяет получить вот такую Doxygen документацию к исходному коду, призванную помочь в понимании внутренней кухни при разработке новой функциональности.

[mapron]

Хорошо, спасибо за отзыв, было интересно узнать еще одну точку зрения!

[arvitaly]

pvs скоро станет компилятором?

[SvyatoslavMC]

Нет)

[Andrey2008]

А зачем? Думаю, что никогда.

[Antervis]

Кстати, насчет компилятора. PVS использует фронтенд clang'а или собственный? Если собственный, то есть ли планы по переезду на clang?

[Andrey2008]

Собственный. Планов нет, хотя мы дискутировали на эту тему.

[perfect_genius]

Мол, раз PVS находит ошибки лучше компиляторов, то сможет конкурировать с ними? Совсем нет, там ведь конечный код ещё оптимизировать надо, а это целая отдельная наука.

[lieff]

Есть неплохая альтернатива cmake — mesonbuild.com.

[SvyatoslavMC]

Тоже можно глянуть код (Meson is an open source build system...), но т.к. я постоянно сталкиваюсь с компаниями, которые мечтают о CMake или только начинают внедрять его, пока не представляю, как Mesobuild станет популярнее.

[equeim]

Meson написан на Python. Насколько я понимаю, PVS-Studio его анализировать не умеет.

[lieff]

Компании могут бояться переходить на относительно молодой продукт. А вот всякие опенсорс проекты довольно активно на него переходят. Например:

github.com/freedesktop/xorg-intel-gpu-tools
www.mesa3d.org/meson.html
salsa.debian.org/debian/sshfs-fuse/commit/4085273733b0d79c7fd65a01b9e5ab400f912cb2

А позже и компании могут подтянуться. Так что как альтернатива вполне может состояться.
Лично мне python-like meson синтаксис нравится куда больше lisp-like cmake.

[mapron]

Этот пост про исходники CMake, а не его использование. Слегка оффтопный ваш комментарий, не находите?

[lieff]

Это был ответ SvyatoslavMC, кажется у хабра есть баг, что если отвечать на последнее сообщение, вместо ответа может получиться корневой коммент.

[mapron]

Понятно. Не то что баг, вроде. просто промахнуться легко, сам пару раз так ошибался.

[SvyatoslavMC]

Мне кажется, каждый 2-й хабравчанин так ошибался, тянет на баг дизайна тогда уж.

[podsvirov]

Прошу прощения за каламбур, но в первой непростительной ошибке непростительно обвинять исходный код проекта CMake, так как это исходный код стороннего проекта libuv. В любом случае, спасибо за поиск ошибок. Я уже создал PR в оригинальный проект. Думаю, со временем, исправления перекочуют и в кодовую базу проекта CMake.

[mapron]

То что при разборе ошибок в статьях PVS — часто фигурирует «папочка thirdparty» — я уже давно привык и забил на это) не похоже, чтобы команда анализатора как-то этим озадачивалась.

[podsvirov]

Для справки: правки, из вышеупомянутого PR, били приняты здесь — планы сбываются — программный мир стал на один символ лучше!

[Artalus]

В поддержку podsvirov, ответ одного из разработчиков симейка:

It is worth pointing out that many of the findings are actually the in 3rd-party libraries libuv, libcurl, rhash, and libarchive. Especially the last one seems to contribute many issues. You might want to analyze this one next?

The remaining issues come from CTest, CPack, and the Visual Studio specific code. I am surprised the the core of CMake is actually pretty clean.

[SvyatoslavMC]

Про код из библиотек

То что при разборе ошибок в статьях PVS — часто фигурирует «папочка thirdparty»

«папочка thirdparty» — мечта автора такой статьи, но так исходники разложены в меньше половины случаев. Часто вообще бардак. Также разработчики часто пишут свои библиотеки к проектам и это нормально.

В данном конкретном случае, библиотека называется не libuv, а cmlibuv. Daniel Pfeifer нормально среагировал, просто попросив проверить зависимости отдельно.

podsvirov, Artalus, mapron