Comments 68
В общем распространение IDE это яркий пример известного ныне "технологического диктата" запада для стран второго и третьего мира.
В странах "первого мира" конечно же используют только мейк файлы, но тщательно это скрывают.
Язык make простой и это, в сущности, bash
вообще не баш, иначе ба зачем был нужен мейк
9--Язык make очень прост. Вся спека GNU Make это 226 страниц
прям запредельная простота
В странах "первого мира" конечно же используют только мейк файлы
Да. Разумеется. Я работал в английском автопроме. Прошивки для ECU собирают там из само писных makefile(лов). *.mk подвергают версионному контролю наравне с *.c *.h.
Всех всё устраивает.
Обобщать не стоит. Работал в немецком и американском автопроме, использовали cmake, bazel и bake, каждый хорош и плох по-своему. make и cmake перестают работать в сильно гетерогенных сборках, когда надо запустить 50 разных генераторов в разной последовательности и всё это дело соркестрировать в единый результат, желательно со временем компиляции, измеряемым в минутах, а не часах и днях.
> Всех всё устраивает.
примерно так, мне к примеру тоже без разницы, столько видел ddk, sdk, и пр., удивить трудно, чего никогда не понимал на habr, так это минусования вполне грамотных комментариев из-за того что у людей разный опыт
статья заслуживает внимания, конечно это типа начального чтения, для более серьезного например YOCTO -
В embedded разработке makefile по старинке ручками пишут, всякие autotools / configure для автоматизации, или альтернативы вроде bazel не распространены?
в embedded используют все что подходит по требованиям, например кроме Linux VxWorks 653, makefiles типа полезный ликбез, который всегда пригодится, посмотрите AECS (4.3 Build Subsystem ) -
https://ntrs.nasa.gov/api/citations/20160000333/downloads/20160000333.pdf
Спасибо за ссылку
У NASA есть еще такой хороший док The Power of Ten (Rules for Developing Safety Critical Code) 6 страничек всего
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
В embedded разработке иногда собирают из Cmake, который в свою очередь автогенерирует makefile или ninja.
Например так в ZephyrProject.
Но Cmake скрипты ненадежны для automotive так как часто дают осечки. В if(ы) не заходит например.
много глаз присматривают за CMake включая sandia и cern для тривиальных ошибок, если что возможно давно закрыто -
Я спросил Бинг/Чатгпт, он вспомнил про один баг с комментариями 2002-го года, и изменение в поведении 2014-го. Если очень-очень долго не обновляться, можно наверное словить.
There are a few possible reasons why CMake does not enter an if statement. Some common mistakes are:
Using incorrect syntax for the condition argument of the if clause. You can refer to the Condition Syntax section of ¹ for more details on how to write valid expressions for CMake if statements.
Using a variable name that is affected by Policy CMP0054¹, which determines whether quoted variables should be dereferenced. For example, if you write
if ("${VAR}"), CMake will treat it as a string unless you set CMP0054 to NEW¹.Using end-of-line comments inside an if statement, which may cause unexpected behavior such as skipping the first line of the if body or changing the evaluation of the condition³. It is recommended to avoid end-of-line comments and use separate lines for comments instead.
I hope this helps you debug your CMake issue.😊
Source: Conversation with Bing, 3/18/2023(1) if — CMake 3.26.0 Documentation. https://cmake.org/cmake/help/latest/command/if.html Accessed 3/18/2023.
(2) [Cmake] cmake bug with IF statement and end-of-line comment. https://cmake.org/pipermail/cmake/2002-May/059634.html Accessed 3/18/2023.
(3) CMake IF (something OR something else) - Stack Overflow. https://stackoverflow.com/questions/19144020/cmake-ifsomething-or-something-else Accessed 3/18/2023.
Ну, воще то синтаксис у cmake местами действительно странный. Местами он декларативный - ожидается что он сам разберётся, в каком порядке выполнять инструкции. Местами порядок важен. Местами case insensitivity, местами case sensitivity. endif(условие, которое вроде как должно соответствовать условию в if(), но можно и без него) - полный кринж.
я только что бегло погуглил, во всем интернете включая stackoverflow не нашлось каких-либо свидетельств о багах в CMake вызывающих рандомные несрабатывания if'ов
Вот, пожалуйста. Cmake зашел в if в который не просили
этот ваш Сmake - маркетинговая хохма
Ну не склоняются английские слова, но вы аж в заголовок умудрились своё (ов) воткнуть.
IDE отжирают много ресурсов компьютера
IDE стоят дорого, порядка 3500 EUR
Статья в песочнице ждала с 1980-х?
Make это как пуговицы. Старая, простая и очень полезная вещь.
Старинные. Кованые кузнецом. По 100 грамм каждая.
Если вы собираете из make, то очень вероятно, что у вас получится чистый, аккуратный репозиторий сам собой.
Так вот в чем секрет! :) Нужно не зелёную галочку нажимать, а в консоли make all набирать, и говнокод станет чистый и шелковистый.
Можно очень много ошибок отловить на этапе отработки утилиты make
Создать ошибок. Дебажить ошибки в makefile тот ещё квест.
Не знаю о чем статья. Работаю в IDE за 0 евро. Idea ce, vs code. При этом часто особенно для голанга для сборки использую старый добрый мейк, который вызываю во встроенном в ide терминале. Я вот в итоге и не знаю, автор бы меня похвалил или предал бы анафеме???)))
Не могу ничего сказать насчёт кода на C, но в целом использование Make для меня, как девопс-инженера, действительно очень упрощает автоматизацию. Для этого даже существует целая парадигма "три мушкетёра" — make, docker, compose.
Чет какая то труха в статье.
Иде отжирает не сильно больше браузера. Даже монстр на яве.
Есть IDE общего назначения умеющие во все мс студия, вс крд, клион, кривой эклипс.
Часть бесплатна. Но да, за хорошее надо платить, особенно когда контора делает дела, а не экономит мейкфайлами.
Потому что нефиг хранит описание сборки проекта в хмл. Есть смейки и мезоны для этого.
Тоже что и пункт 4.
Тоже что и 4.
Всегда можно сделать аналоговнетную. Ведь можно... Можно же?
В каком то кб грохнули лицуху на клон эклипса, теперь у дедов, которые сами себя закопали под проприетарную проектную систему весеннее обострение и мейкфайло рейдж.
make это замечательно, только вот есть маленькая такая проблема. Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна. Нет, вызвать компилятор cl6x и его инструментарий из командной строки вам никто запретить не может. Но в тот момент, когда вы захотите сделать что-то сложнее Hello World и начнёте использовать NDK, IPC и прочие библиотеки для работы с этими процессорами, вам потребуется великий и ужасный Code Composer Studio. Отладчик опять же у них работает только в нем.
Максимум, чего мне удалось добиться - запуск процесса сборки из консоли, что позволяет использовать sublime или qtcreator в качестве редактора кода.
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Поздравлю вас! Вы подпали под "технологический диктат". Хотя это и не удивително для политики США(Texas Instruments).
Вот попросите у TI техподдержки репозиторий из make.
Посмотрим, что они вам ответят.
Даже IDE-IAR не оказывает техподдержку по сборку из make.
Что уж говорить про TI
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Понятное дело. Это также сделано, чтобы разработчики IDE (TI) во всю могли добавлять всяческие программные закладки, такие как слив Ваших исходников в здание с пятью углами, уделенное отключение и всё на что им только фантазии хватит.
Это чтобы Вас под контролем держать. На ошейнике.
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Да что вы говорите? https://habr.com/ru/articles/726352/
Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать? Почему нельзя сделать все структурированно, в xml или json. У каждого проекта есть корень, в нем указывается имя проекта, далее могут быть секции с конфигурациями, секции со списками файлов, у каждой секции опять же должно быть имя в корне и структурированное содержимое. Каждая конфигурация должна содержать внутренние секции, отвечающие за разные группы опций компиляции. Если нужны разные компиляторы и прочие инструменты - тоже можно придумать соответствующий тип секции, с явным указанием что это "инструмент сборки" и именем. То есть, формат должен быть такой, чтобы его можно было максимально прозрачно отобразить на GUI окно настроек проекта.
Как по мне, так формат makefiles это абсолютнейший, лютейший бред
В далёкие времена, когда компьютеры были большие, автор запилил себе программу с таким вот странным форматом, с табуляциями. Народу понравилось.
Почему нельзя сделать все структурированно, в xml или json.
Не нужно. Это машинные форматы, кодированные в текст. Для человеков есть 100500 других систем управления сборкой. scons, cmake, ninja.. Некоторые IDE их понимают.
Собственно и была целая эра сборщиков декларативных на xml и json. ANT, ms build, xbuild, maven, ... Имя им легион - неудобно, многословно, проблемы с порядком выполнения, уйма тайного знания. Любой кто на этом строит сборки рано или поздно понимает, что даже динозавры типа make удобнее в части управления задачами. Собственно дьявол во всяких плагинах, например в части ракетных менеджеров. Но где этот вопрос решён нормальными консольными командами или прямо встроено в тулчейн опять же проблемы с мейком нет. Как краевед говорю, который 15 лет евангелировал ms build, затем maven и большие проекты с кастомными плагинами на грэдле собирал.
Так вот yaml лучше xml и json, процедурное типа градла лучше декларативного типа мавена, мейк и баш вообще всего лучше решают всё в лоб и по простому и где есть возможность действительно проще быстрее и понятнее сделать на них
Смешно. make, вообще-то, на десятилетия старше и XML, и, тем более, JSON. Почему же его авторы не использовали эти форматы? Вот что-то даже не знаю...
А как авторы make могли использовать то чего нет. Я вам раскрою может секрет, но xml и json не популярны не только в девопс, но и в обработке данных, так как избыточные и не поточные, там царствуют добрые старые csv и прочие такие форматы.
Xml и json это форматы для сериализации древовидных структур с сохранением (особенно xml) метаданных. Зачем это всё в make, который является сборочным скриптом?
Вам то чем они так милы. Целое десятилетие было царствование xml, wsdl soap и всё такое, осталось только в мире легаси и кровавых межведомственных систем. Потом типа rest, json это наше всё... Ну и что по сути сейчас наметился возврат к классическим бинарным форматам но там с блэкджеком и прочим, типа протобафа. Json же смещается в более нишевое использование. Форматы, тренды, приходят и уходит. А бессмертная классика типа мейков и башей остаётся независимо от степени мощности своего синтаксиса. Причина одна они чётко знают свою работу и хорошо её делают)))
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
IDE монолитные и неделимые. Если вы захотите поменять препроцессор, компилятор или компоновщик, а остальные фазы ToolChain(а) оставить как есть, то ничего из этого не выйдет, так как капот IDE закрыт на замок.
О как, а мужики по не знают ...
IDE стоят дорого, порядка 3500 EUR на один компьютер.
Мы в одной вселенной живем?
IDE(шные) xml очень слабо документированы или не документированы вовсе. У всех вендоров xml имеет свой особенный язык разметки.
А что, все должны иметь один стандарт разметки? Да, документированы не очень, но Вам точно нужно лезть под капот, если все работает правильно?
Затруднена сборка из консоли.
А никто и не обещал такое, хотя многие IDE позволяют сделать make файл и дальше делайте с ним , что хотите.
Обратная несовместимость с новыми версиями IDE
То есть при использовании make можно код с фичами C++17 скомпилировать под C++11 компилятором - честно говоря не знал о подобных возможностях, Вы открыли мне глаза.
Вы собираете код с помощью СMake?
Я понимаю, что есть cmake --build, но строго говоря вызовы компилятора и линкера делает не cmake, а " a native build tool ". То есть, если было cmake -G Ninja , то сборка всё-таки с помощью ninja.
Тут небольшая путаница в терминологии: Cmake - это способ управления компилятором. IDE (integrated development environment) - это интегрированная среда разработки, куда помимо инструментов управления компилятором, входят другие полезные вещи, вроде отладчика, терминалов, инструментов работы с репозиториями и т.п.
Я вообще не представляю, как без помощи IDE производить отладку программы?
И да, если мы говорим про Embedded, то Eclipse (и IDE на нём базирующиеся, наподобие STM Cube IDE, ESP-IDF), VSCode + PlatformIO - бесплатны. Очень хороший инструмент VisualGDB для Embedded систем стоит 100 долларов в год (https://visualgdb.com/buy/).
Я вообще не представляю, как без помощи IDE производить отладку программы?
Тут есть 4+ ответа:
1--> Использовать связку GDBClient + GDBServer и отлаживать код из командной строки.
https://habr.com/ru/post/694708/
2--> Отлаживать код через интерфейс командной строки CLI поверх UART.
https://habr.com/ru/post/694408/
3--> В коем-то веке покрывать код модульными тестами
https://habr.com/ru/post/698092/
4--> Использовать другие косвенные признаки отладки кода: HeartBeat LED, Утилита arm-none-eabi-addr2line.exe, Assert(ы), DAC, STMStudio, Health Monitor
https://habr.com/ru/post/681280/
Разработчики встраиваемых систем такие смешные. Очень быстро (особенно если писать на ассемблере для примитивных контроллеров x51, AVR, PIC) возникает ощущение всемогущности. Сам таким был.
Потом приходят маркетологи и просят написать под Cortex-A, свой блютуз-стек, с утилизацией многоядерности, прикрутить толстую внешнюю библиотеку, что-нибудь из мира Unix и это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву. Потому что он не может Cortex-A, RISC-V, MIPS, C++ - там странный кривой диалект, не может стырить толстую либу с гитхаба. А работа под отладчиком это для маленьких детей и большие пацаны так не пишут.
Итого, есть два сценария - первый, самый распространенный, вы продолжаете использовать свой любимый инструмент и отказываетесь от работ, которые вы не в состоянии выполнить.
Второй сценарий - вы просто используете то что используется в толстой внешней библиотеке которая вам необходима, и которую вы не напишете никогда, потому что она стоит сотен человеко-лет разработки.
Но самый зубастый сценарий - все писать под Линукс, без отладчика, с любой необходимой системой сборки: cmake, ninja, makefile, bazel... как со своей родной. Если действительно нужен отладчик, то лучший вариант gcc с платным плагином для Visual Studio. Вы сразу получите все возможности работы с С++ и удобный аппаратный отладчик.
это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву.
В программировании микроконтроллеров самооценка еще рушится при переходе на очередную RTOS.
В каждом проекте взяты за основу разные RTOS(ы).
Если вы senior в FreeRTOS с 10 годами опыта за плечами, то при переходе на TI-RTOS вы мгновенно превратитесь в Junior(а).
Если вы senior в TI-RTOS с 15 годами опыта за плечами, то при переходе на RTOS Zephyr вы мгновенно снова превратитесь в Junior(а).+ учите CMake, Ninja, KConfig и DeviceTree.
Затем та же история с RTEMS 5, Tizen, VxWorks, ThreadX и так далее?
Поэтому в программировании микроконтроллеров Senior может на следующий день стать Junior(ом) и это более чем нормальное явление.
В профессии программист MK развитие и экспертиза обнуляется каждые 2-3 года.
у меня картина мира следующая.
Чиновники США в 60х оплатили разработку новой операционной системы. Туда были приглашены реальные звезды, технологические компании и университеты. Это проект Multics. Проект провалился, так как сроки были нереальные. Но именно там были придумали сущности: файл, директория, файловая система...
На обломках возникла сильно кастрированная операционная система UNIX. (яндекс голосовой переводчик часто переводит это название как "евнух-кастрат" и это действительно одна из версий происхождения названия) Система получилась удачной и чиновники США стандартизируют ее как проект POSIX. Итак, человечество получило единый стандарт для того чтобы портировать приложения. Прямо сейчас POSIX-приложения можно портировать на Андроид, МакОС, игровые приставки, суперкомпьютеры, Линуксы, ФриБСД и так далее.
В этом мире все должно поставляться в исходниках.
Проекты make (autotools), cmake, ninja и так далее это просто решение этой задачи портирования.
Я думаю ваши проблемы от незнания Линукса. Вы пытаетесь заучивать рецепты. Хотя, если бы имели навыки и понимание, то ни одна из сущностей вашего перечисленного не казалось бы чем-то новым и удивительным.
Мне тоже казалось что Линукс это всего лишь подобие Винды. Нет. Расстояние от Линукса до Винды такое же как от Винды до пальцевого интерфейса Айфона (Андроида).
Линукс (UNIX) это долго и очень больно для изучения. Порог вхождения очень высокий.
Но с каждым шагом есть ощущение что вы возвращаетесь домой. Здесь Си, наконец-то, базовый родной язык. Но после преодоления порога уже ничего не шокирует. Ничего не вызывает раздражения и новые инструменты изучаются легко и естественно. И вы больше не джуниор.
Я думаю ваши проблемы от незнания Линукса.
Где linux с его POSIX, и где микроконтроллеры..
перечисленные автором проблемы: CMake, Ninja, KConfig, DeviceTree, Tizen, VxWorks и так далее это все из мира UNIX.
Где linux с его POSIX, и где микроконтроллеры.
Сейчас микроконтроллеры во всей пригожей Европе программируют из-под Zephyr Project. А там надо знать west, Yaml, Python, KConfig, DeviceTree, CMake и Ninja как отче наше.
https://zephyrproject.org/
Я думаю ваши проблемы от незнания Линукса.
В микроконтроллерах(МК) нет MMU, поэтому Linux на МК не запускают. На МК крутят разнообразные как снежинки RTOS(ы).
UNIX это эталонная реализация Машины Тьюринга поверх фоннеймановской архитектуры. И мы живем с этим много лет, пока не появится некий новый квантовый компьютер или биологическая вычислительная система для которых придется все проектировать заново.
То есть все ваши ОС являются проекциями базовой системы. Достаточно понять первичную чтобы разобраться.
DeviceTree - это такое "ардуино" для взрослых, общее описание оборудования. Придумали когда устали бороться с зоопарком железа. Сейчас используется везде, кроме x86.
KConfig - часть системы сборки ядра Линукс
VxWorks - POSIX система, те же яйца только в рилтайме
Tizen - снова Линукс.
Zephyr - опять распотрашенный Линукс. Весь инструментарий оттуда.
язык Си - бессмертный пока существует POSIX
С++, большинство прочих языков программирования долгое время существовали как надстройки над бэкендом Си и его стандартной библиотеки.
Все эти RTOS, как FreeRTOS содержат те же мьютексы и семафоры только в сильно кастрированном виде. Вернее чаще это голый планировщик задач.
ucLinux смотрит на вас с осуждением xD
Назовите хоть одну организацию, где бы в самом деле применяли ucLinux на микроконтроллерах.
@aabzel, я бы с радостью, но тут такое дело... К сожалению они мне не отчитываются о выборе ОС, RTOS и так далее.
Но у достаточно современных МК более чем достаточно для этого. Один из примеров, с которым я имел дело в свое время: Moxa UC-7101, там внутри ucLinux.
Соответственно, те кто используют вышеуказанное устройство - используют ucLinux, на микроконтроллере с ARM9 ядром
Для отладки консоль и только консоль. Обычно отладка нужна для капризных интерфейсов, работающих в реальном времени и фоном. Поэтому все что остается делать - складывать все переменные и регистры что могут понадобиться в массивы внутри прерываний, а потом считывать их консольным gdb. По другому заглючивший интерфейс отлаживать я хз как. ИМХО в остальных случаях отладка не нужна, т.к. какой нибудь алгоритм можно и тупо на компе погонять, проверить.
Для отладки консоль и только консоль.
Согласен. Нужен Debug CLI terminal over UART.
Все ARM Cortex-M давно уже по JTAG или сокращенному варианту его же (SWD). По нему же зашиваются, по нему же отлаживаются. У меня пока ручки до CC2640 Ti и ESP32 с Nordic NRF51 не дотянулись (их думаю через opencocd, swd over ftdi). Но вот STM32 давно уже по gbd через st-link utility по swd, причем под линуксом, в репозиториях уже все есть.
del
Почему важно собирать код из скриптов