Comments 29
Имел «удовольствие» попробовать сделать некоторые доработки в кодовую базу CMake. К сожалению, там не только по коду статический анализ плачет — высокая связность компонентов приводит к тому, что почти невозможно правки делать только в одном месте. После работы с сорцами QBS я реально плакал, кусал локти и матерился(
Если у кого-то был положительный опыт работы с исходниками CMake — поделитесь им, пожалуйста.
По поводу «как тут с разыменованием нулевого указателя не падает» — у меня субъективно сложилось ощущение во время отладки, что там по большей части условий управление не ходит вообще. Т.е. смотришь на условие и не можешь найти способ чтобы оно выполнялось (опять же не берусь утверждать что там есть мертвый код). В общем, с таким неочевидным потоком выполнения кода там крайне легко допускать такие ляпы.
Надеюсь кто-то из разрабов CMake станет пользоваться PVS :)
Если у кого-то был положительный опыт работы с исходниками CMake — поделитесь им, пожалуйста.
По поводу «как тут с разыменованием нулевого указателя не падает» — у меня субъективно сложилось ощущение во время отладки, что там по большей части условий управление не ходит вообще. Т.е. смотришь на условие и не можешь найти способ чтобы оно выполнялось (опять же не берусь утверждать что там есть мертвый код). В общем, с таким неочевидным потоком выполнения кода там крайне легко допускать такие ляпы.
Надеюсь кто-то из разрабов CMake станет пользоваться PVS :)
После работы с сорцами QBS я реально плакал, кусал локти и матерился(
Если у кого-то был положительный опыт работы с исходниками CMake — поделитесь им, пожалуйста
тем временем QBS задепрекейтили в пользу CMake. Боль, тоска, печаль
QBS как таковой не задепрекейтили. Задепрекетили использование QBS в качестве сборочной системы Qt и ее продвижение в Qt Creator. Выпиливать ее поддержку не будут, конечно, т.е. особых рисков использовать ее для своих проектов дальше — нет.
(ну и опять же «работать с исходниками» != «работать с самой сборочной системой»).
Как пользователь CMake я ей вполне доволен, и считаю что переход на CMake для Qt (как было с KDE) — решение хотя и спорное, но в целом взвешенное и даст определенные преимущества.
(ну и опять же «работать с исходниками» != «работать с самой сборочной системой»).
Как пользователь CMake я ей вполне доволен, и считаю что переход на CMake для Qt (как было с KDE) — решение хотя и спорное, но в целом взвешенное и даст определенные преимущества.
QBS как таковой не задепрекейтили
судя по посту в официальном блоге задепрекейтили именно QBS как таковой. А сборку Qt/QtCreator'а на QBS так и не перевели, чтобы депрекейтить.
тем временем QBS задепрекейтили в пользу CMake. Боль, тоска, печаль
Ну не так уж все плохо, в результате этого перехода разработчики Qt наконец-то запили в cmake официальную поддержку pch: https://gitlab.kitware.com/cmake/cmake/merge_requests/3553
Так что я думаю часть возможностей qmake/qbs перекочует в cmake.
После работы с сорцами QBS я реально плакал, кусал локти и матерился
Так CMake или QBS? Насколько мне известно, это два абсолютно независимых друг от друга программы.
К вопросу о положительном опыте работы с исходниками CMake. У меня есть такой, как я считаю, положительный опыт.
Я разработал и внедрил CPack IFW Generator, который был добавлен в версии 3.1.
Также я добавил поддержку опции проекта CMake_BUILD_DEVELOPER_REFERENCE, которая позволяет получить вот такую Doxygen документацию к исходному коду, призванную помочь в понимании внутренней кухни при разработке новой функциональности.
Я разработал и внедрил CPack IFW Generator, который был добавлен в версии 3.1.
Также я добавил поддержку опции проекта CMake_BUILD_DEVELOPER_REFERENCE, которая позволяет получить вот такую Doxygen документацию к исходному коду, призванную помочь в понимании внутренней кухни при разработке новой функциональности.
pvs скоро станет компилятором?
Есть неплохая альтернатива cmake — mesonbuild.com.
Компании могут бояться переходить на относительно молодой продукт. А вот всякие опенсорс проекты довольно активно на него переходят. Например:
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.
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.
Этот пост про исходники CMake, а не его использование. Слегка оффтопный ваш комментарий, не находите?
Это был ответ SvyatoslavMC, кажется у хабра есть баг, что если отвечать на последнее сообщение, вместо ответа может получиться корневой коммент.
Прошу прощения за каламбур, но в первой непростительной ошибке непростительно обвинять исходный код проекта CMake, так как это исходный код стороннего проекта libuv. В любом случае, спасибо за поиск ошибок. Я уже создал PR в оригинальный проект. Думаю, со временем, исправления перекочуют и в кодовую базу проекта CMake.
В поддержку 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.
Про код из библиотек
В данном конкретном случае, библиотека называется не libuv, а cmlibuv. Daniel Pfeifer нормально среагировал, просто попросив проверить зависимости отдельно.
podsvirov, Artalus, mapron
То что при разборе ошибок в статьях PVS — часто фигурирует «папочка thirdparty»«папочка thirdparty» — мечта автора такой статьи, но так исходники разложены в меньше половины случаев. Часто вообще бардак. Также разработчики часто пишут свои библиотеки к проектам и это нормально.
В данном конкретном случае, библиотека называется не libuv, а cmlibuv. Daniel Pfeifer нормально среагировал, просто попросив проверить зависимости отдельно.
podsvirov, Artalus, mapron
Sign up to leave a comment.
CMake: тот случай, когда проекту непростительно качество его кода