Разработка софта это не только про код. Разработка софта это во многом про Toolchain(ы). Прежде чем начать исполняться исходники проходят гигантский путь и с каждым годом выходят все более и более массивные системы сборки. Современные технологии разработки софта настолько многостадийные, что понять их не просто.  Toolchain это как длинный конвейер. Есть действия, которые следуют одни за другими. После чего получается результат (артефакты). Большинство IDE(IAR, KEIL, MsVisualStudio и пр.) скрывают весь этот конвейер преобразования файлов. И программисты, которые привыкли торчать в IDE(шках) часто даже не догадываются, что в программировании существует что-то кроме *.h и *.с файликов. В этом плане IDE оказывают своим покупателям медвежью услугу, так как программисты привыкшие работать только в IDE имеют тенденцию становиться очень слабыми разработчиками.  По-настоящему разобраться как варятся артефакты сложно. Как же это сделать?  Надо прибегнуть к народной мудрости. Как говорит английская пословица: "картинка стоит тысячи слов". Значит надо нарисовать картинку, то есть схему ToolChain(а).  Зачем нужны эти пресловутые схемы ToolChain(ов)?  1--Например фирма chip maker может получить преимущество на рынке, если у нее есть качественная, понятная, доступная и разнообразная документация. 2--Схема ToolChain(а) позволит быстро ввести в курс дела нового сотрудника-программиста в компании. Как же нарисовать схему ToolChain(а)? Тут есть 2 варианта: [1] Рисовать схему самому, мышкой в программе Inkscape.exe.  Плюс:  a) Можно добиться очень высокой степени изобразительности и гибкости. Как тут. Можно задействовать слои, линейки. Те кто учил в художественной школе композицию тут могут оторваться по-полной.   Минусы:  a) Ручное рисование весьма утомительно. Обязательно наступят боли в запястье.   b) Использование мышки в программировании вообще считается дурным тоном.  c) Трудно подвергнуть *.svg файл версионному контролю. Конфликты при git merge *.svg так как это, в сущности, *.xml(ка). d) Трудно вставить новый блок так как надо всё снова двигать, выравнивать. [2] Составить описание графа или дерева на языке разметки графов Dot и автоматически одноименной утилитой dot.exe сгенерировать схему графа. Плюсы:  a) Быстро. b) Четко.  c) Легко перерисовать. Легко вставить новый блок.  d) Легко подвергнуть версионному контролю.  e) Легко распределить между разными разработчиками сложной блок-схемы. Минусы:  a) Надо очень хорошо знать синтаксис и семантику языка Dot. Это кластеры, свойства вершин, свойства ребер, способы раскраски (названия цветов), свойства начала линий, свойства конца линий. Ранги узлов. Настройки авто трассировки и прочее.    b) Схема может не скомпилироваться рендером, если есть ошибки в синтаксисе языка Dot.  c) Cхема может отрисоваться (отрендериться) самым неожиданным для автора образом. Тем не менее, как по мне, второй вариант выглядит намного предпочтительнее и позитивнее так как надо меньше пользоваться мышкой. Да и к схемам Toolchain(а) обычно не предъявляют требований высокой степени художественности. Лишь бы поскорее понять как работать с кучей разрозненных утилит. Какой инструментарий потребуется для авто генерации блок схем? Если коротко, то это cpp, dot, make, chrome. Прежде всего надо накатить компилятор Dot файлов. Советую брать с официального сайта https://graphviz.org/. Сейчас там версия 6.0.1. Можно конечно и из CygWin скачать Dot, но там версия устаревшая. Старый Dot может упасть в run-time из-за переполнения стека при отрисовке сложных графов. Не забываем прописать путь к dot.exe в переменную PATH. Писать код на голом языке Dot это не эффективно. В реальных схемах слишком много повторяющихся синтаксических конструкций. Поэтому объединим Си(ишный) препроцессор (утилита cpp.exe) с языком dot.   С препроцессору (cpp.exe) вообще все равно какой там язык (assembler, C, C++, DeviceTree, Kconfig, скрипты компоновщика *.ld). Задача утилиты cpp.exe это банальная вставка и замена текста и точка. Например деревья устройств в Linux тоже обрабатываются препроцессором cpp. И это всех более чем устраивает. Поэтому будем и мы также использовать препроцессор cpp для обработки и подготовки исходного текста на языка dot. В качестве примера исследуемого сложного ToolChain(а) рассмотрим Zephyr project.  Определим только несколько полезных макросов для языка dot Определим файл *.doti с утилитами, которые будут участвовать в ToolChain(е). *.doti - значит, что это include. Определим  *.doti файл со списком расширений файлов, которые будут участвовать в ToolChain(е) Определим файл со связями утилит и файлов между собой. Теперь надо собрать, собственно, сам *.dot файл для утилиты рендера dot.exe, преобразовать *.dot в векторную графику *.svg и отобразить рисунок на экране монитора прямо в браузере. Вот такой микро-конвейер надо реализовать. Тут нам как раз поможет утилита make. Вот ее код Для любителей системы сборки ninja я тоже накропал build.ninja скрипт  В результате мы собрали вот такую замечательную блок схемку ToolChain для системы сборки Zephyr. Успех! Теперь все как на ладони. Причем при просмотре *.svg из браузера даже Ctrl+F поиск есть! Супер!  Буквально пара слов про Zephyr. Видно, что Zephyr собирает проекты в два супер этапа. Сначала Zephyr собирает конфигурацию. Результат сборки конфигурации это Makefile или build.ninja плюс несколько заголовочных файлов *.h, затем собирают сами артефакты на основе собранной ранее конфигурации. На схеме все прекрасно видно. Рулит всем внутри фактически CMake. Но есть Python скрипты west, которые запускают CMake. Вот полный *.dot код с выхода препроцессора для тех, кто хочет изучить схему под увеличением  ShowRoom схем ToolChain(ов) Вот классическая схема ToolChain для сборки прошивок под микроконтроллер nrf5340. А это схема ToolChain(а) при разработке топологии для электронной платы Это схема метаморфоза файлов для черчения Вывод Как видите синергия препроцессора cpp и языка разметки Graphviz может оказаться очень полезна и эффективна в разработке софта и всяческой документации. Это позволяет высвободить тонну времени от ручной перерисовки. Можно также из Graphviz генерировать архитектуры систем на чипе SoC, схемы электрических цепочек, графы задач из task tracker(а), нейронные сети, конечные автоматы, схемы метро. Да всё, что только душе угодно, что имеет графо образную природу.  Язык Graphviz настолько хорош и универсален, что его следовало бы включить в университетскую программу обучения в технических факультетах в качестве одной лабораторной работы по компьютерным технологиям.  Особенно советую обратить внимание на связку сpp.exe/dot.exe/make.exe тем кто работает техническими писателями и схемотехниками. Это тот самый случай, когда программирование на Graphviz может принести пользу. Ссылки про язык Dot https://habr.com/ru/post/682346/ https://habr.com/ru/post/499170/ https://habr.com/ru/post/337078/ https://habr.com/ru/post/662561/ https://habr.com/ru/post/258295/   Embedded SW/Firmware Engineer