Комментарии 48
Какие преимущества у makefile перед кроссплатформенным cmake? Почему вы именно его используете?
Почему бы просто не пробежаться по исходникам и автоматически собрать граф зависимостей?
Какие преимущества у makefile перед кроссплатформенным cmake?
makefile инвариантен к языку программирования.
Утилиту make можно использовать не только для дирижирования процессом сборки кода программ.
Утилита make может также управлять авто генерацией преобразования расширений файлов для черчения или управлять сборкой документации, управлять DevOps(ом). Make можно использовать по-разному, как только фантазии хватит. Ибо Make инвариантен к языку программирования.
В вашем сообщении вместо make напишите cmake - результат не изменится :)
Просто make он ближе к физике процесса.
Make непосредственно управляет сборкой, а CMake это надстройка над Mаke. СMake генерирует Make скрипты.
СMake выступает как уровень абстракции (автопилот для системы сборки) чтобы абстрагироваться от конкретных генераторов (Ninja /Make/ IDE).
Cmake это не надстройка над make. Генерация мейкфайлов - лишь очень маленькая часть функциональности. Посмотрите сколько различных видов выхлопа там поддерживается (хотя в большинстве случаев сейчас используется ninja, не make).
Да, синтаксис cmake порой оставляет желать лучшего, но он всё равно намного ближе к программированию.
Почему бы просто не пробежаться по исходникам и автоматически собрать граф зависимостей?
Дак, в этом тексте это и проделано.
Так можно же просто взять doxygen
Разве doxygen это про графы?
На сколько я помню doxygen он просто генерировал wiki, которая подписывает назначение аргументов функций, при этом надо было еще написать явно кучу комментариев согласно спец синтаксису, чтобы doxygen всё понял без ошибок.
И это было похоже на мартышкин труд.
Если строить граф на основе каждого include(а), то такой граф будет очень перегружен. И анализировать его будет очень трудно.
Согласен. Тут вопрос, какая стоит цель. Мне полученный в статье граф не кажется особо полезным, чтобы вникнуть в проект. Из хорошего: перечень используемых модулей и знание, что какие-то модули точно не связаны (если автор GVI не врёт). Может быть, модули надо инициализировать в порядке топологической сортировки, но это не точно, вдруг какие-то из стрелок как раз значат "инициализирует". Я бы рассматривал то, что показано в статье, как скелет инструментов и процессов, на который далее можно нарастить мясо из дополнительных сведений — Graphviz это позволяет.
Мне полученный в статье граф не кажется особо полезным, чтобы вникнуть в проект.
Хорошему программисту вообще и сорцов достаточно.
Тут вопрос, какая стоит цель.
Меня схемотехники попросили составить "документацию на ПО". Два дня не понимал, что это значит (документация на ПО) и в результате вот, я им и дал граф зависимостей между программными компонентами.
Звучит как формальное решение своей задачи "дать документ, который устроит схемотехников". Непонятно, какую их проблему решит такой граф, а если нужна была какая угодно диаграмма, то и граф включений сошел бы. К чему тогда слова про подключение к проекту новых сотрудников?
Исходников достаточно только в небольших проектах. Если взаимодействует много подсистем, да еще на разных языках (это не про embedded, конечно), то очень полезно видеть, кто к кому обращается и зачем, где и какая информация доступна.
К чему тогда слова про подключение к проекту новых сотрудников?
Показалось, что схема зависимостей тоже немного поможет и в этом.
Звучит как формальное решение своей задачи "дать документ, который устроит схемотехников". Непонятно, какую их проблему решит такой граф, а если нужна была какая угодно диаграмма, то и граф включений сошел бы.
У меня был случай, когда в отделе РЭА ко мне пришел начальник-схемотехник и попросил, чтобы я составил документ-требования к транспортировке программного обеспечения (ПО) железнодорожными видами транспорта. Вот так и живем...
Непонятно, какую их проблему решит такой граф, а если нужна была какая угодно диаграмма, то и граф включений сошел бы.
Уменьшит неопределенность того, что происходит в софте. Создаст чувство контроля над ситуацией.
Тут вопрос, какая стоит цель.
Ещё начальство отдела РЭА хочет получить какую-то абстрактную документацию по программному обеспечению firmware.
При этом смотреть код они не хотят. И что мне им предоставить?
Или не хочет, а только говорит. Для начала сходить узнать, что им на самом деле надо. Может быть, у них реальная проблема, но для решения которой нужно совсем другое. Может, им позарез надо выиграть пару дней под видом "программист пишет документацию", и можно делать что угодно. Может, они хотят прикрыть свой провал тем, что вы не даете им то не знаю что, и надо было эскалировать ситуацию. Может, они самодурствуют, но вы сумели извлечь из этого то, что изучили Graphviz и сделали основу для документации — без тени иронии, отличный корпоративный маневр.
О doxygen имеет смысл говорить лишь после того, как код сперва будет покрыт модульными тестами.
Хм, тогда проще просто сразу переписать на Rust.
На самом деле, не вижу тут никакой связи, документация на код вещь важная, тесты тоже, да инструменты которые позволяют делать и то и то лучше с самого начала интегрировать в проект.
Но вот использовать самодельные инструменты лучше если каким-то популярными вообще никак не решить проблему, а то иначе вместо одной проблемы их станет несколько.
Cамая лучшая документация к коду - это модульные тесты.
https://habr.com/ru/articles/698092/
В модульных тестах сразу видно как заполнять прототипы функций и что делать с результатом работы функции.
Так можно же просто взять doxygen
Утилита grep работающая в папке с репозиторием при определенной сноровке может выдать отличную документацию.
В программировании микроконтроллеров программы часто строятся иерархично.
По факту чаще наблюдается повальное злоупотребление перекрестными включениями, когда вся иерархия сливается в один общий неразрывный комок.
По-моему, Doxygen выдает примерно то же самое, только сразу из *.c кода и с меньшими усилиями
Для Doxygen надо писать много комментариев в коде согласно спец. синтаксису.
Это можно замучиться писать много комментариев.
Графы включения и использования Doxygen генерирует не используя эти коментарии.
Реально замучиться можно разбираясь в коде без коментариев (есть опыт).
Doxygen будет строить монструозный граф для всей кодовой базы, а если компоновать gv из make, то для каждой отдельной сборки строится её отдельный и собственный граф зависимостей в котором нет ничего лишнего.
Лишний код из соседней папки просто не участвует.
И в это весь смысл.
Реально замучиться можно разбираясь в коде без коментариев (есть опыт).
Лучший комментарий- это адекватное название функций и переменных.
Как по мне, дак лучшая документация к коду - это модульные тесты.
https://habr.com/ru/articles/698092/
Сразу видно как заполнять прототипы функций и что делать с результатом работы функции.
Гм. А что, IDE строить граф зависимостей не разучился?
Вы смотрели, как ровно такая же задача решена в modm? Я сам не очень люблю всякие новомодные ninja и scons, но признаю, что просто описать зависимость в xml всё таки удобнее, чем редактировать .gvi.
Так мы оказывается не зависимости генерируем (что бы это не значило), а граф зависимостей.
Граф не полный, куча листьев в воздухе висит: Фифо, таски, црц и др.
То есть всё в программе живёт где-то там.. а основной код (суперцикл) его не использует
Хорошая документация поможет быстро ввести в курс дела новых людей.
Хорошая — поможет.
Но вот эта каша — это плохая документация. Точнее, это вообще не документация — это плохо сделанная иллюстрация к ненаписанной документации.
Если раскрасить ребра, то будет понятнее. Graphviz как раз позволяет раскрашивать ребра.
Не будет. Каша превратится в винегрет, а понятнее — не будет.
Любая автогенерируемая псевдодокументация требует серьёзной обработки руками для превращения её в настоящую документацию. Без этого — просто способ дёшево нашлёпать много картинок (текстов, etc.) плохого качества, we call this beta because its betta than nothing.
То есть, простительно, когда к тебе ворвались с криком «у нас новый человек, надо к понедельнику срочно ввести его в курс дела!», а сейчас уже четверг и до этого никто никакой документацией вообще не занимался. К вечеру ты вот такого нагенерил, в пятницу человека в это потыкал, вроде он чего-то понял.
В остальных случаях — нет, это не документация и тем более не «хорошая документация».
Это надо писать жалобу разработчикам аглоритма трассировки, который заложен в пакет утилит graphviz. Или искать другую тулу для рендеринга графов.
Со своей стороны я нормально сделал индексацию и сбор зависимостей.
Graphviz архаичный какой-то доисторический,
есть более современные средства:
Генерация зависимостей внутри программы