Comments 8
Полезно. На днях похожей экзотикой занимался: gcc-arm-none-eabi, openocd, cmake, ninja-build. Работает без запретных технологий проксирования на 3 буквы, в отличии от куба и ломанного Keil
У меня проекты в github или gitlab лежат и там нужны "технологии" без keil, iar, eclipse и пр. Тем более, когда вся "кухня" должна быть кроссплатформенной и желательно быть "совместимой" по окружению разработчика для соседних связанных проектов.
Например, отладкой занимаюсь в VS Code для разных типов проектов для одной системы. То же касается CI/CD.
Я выше не написал про окружение разработчика (Windows, Linux): ARM GCC, CMake, Ninja, Qemu, Renode, VS Code.
Практический смысл особенно заметен, когда у прошивки появляются несколько вариантов. Общую часть конфигурации можно сохранить, а отличия микроконтроллера, платы или набора функций вынести в профили. В YAML видно, какие исходники и компоненты входят в сборку. При просмотре изменений в Git можно сразу заметить, например, добавление библиотеки, смену MCU или изменение флагов компиляции.
Все то же самое можно прописать в make скрипте обыкновенными переменными окружения.
Дак зачем же на самом деле понадобился yaml?
Наверное можно, но во-первых, он не кроссплатформенный сам по себе, заколебётесь потом с путями проблемы решать в разных системах, а во-вторых, это был бы ооочень большой оверхед повторить тот же функционал, что у меня под капотом находится.
В здравом уме народ давно слез с make на другие конфигураторы.
У меня 1500 разных конфигураций в CI тестируются (на github) для разных MCU и backend'а. Вот для чего на самом деле этот yaml понадобился - скрыть реализацию подключения всего того, что можно подключить.
Мне это понадобилось для унификации при разработке: прототипы на Arduino, проекты на CMSIS/HAL/LL/CubeMX. Всё в одном стиле.
Сейчас поддерживается как YAML, так и TOML формат для файла конфигурации.
От сборки до проверки на плате: набор открытых инструментов для разработки под STM32