Comments 46
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение.
Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32.
Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
Ленивые юзеры получают франкенштейнов. Но это их проблемы
Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь:
Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно.
Согласен в Вами. Одно достоинство Eclipse ARM plugins всё таки есть.
Если Вы ещё пока слабо разбираетесь в языке сборки make, то Вы можете внимательно проанализировать те makefile(ы), которые для Вас любезнейшим образом синтезировали Eclipse ARM plugins и, на основе этого, раздербанить их и написать свои более структурированные и модульные makefile(ы). Вот, пожалуй, единственное достоинство ARM plugins для Eclipse.
Прошивку собранную c помощью Eclipse ARM plugins можно сравнить вот с этим.
Ну не отсортирован cproject, и чем это мешает?
diff одинаковых сборок достигает 99%
а если они начнут писать make вручную, их проекты вообще перестанут собираться.
make файл пишется один раз и слабо меняется со временем.
Причем make файл можно сгенерить из STMCubeMX.
И нажать F5 (refresh) ну ни разу не проблема.
Проблема, если у Вас сборки собирает Jenkins ( почитайте про CI / CD)
И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает.
Плюс разработки в IDE в том, что можно годами высасывать из организации зарплату за то, что через Make скрипты сборки можно сделать максимум за 3-4 месяца. Именно по этой причине embedded стартапы не используют IDE, а используют, как раз , именно скрипты сборки (Make, CMake).
В одной западной компании мы делали прошивки для заурядных плат, которые, по сути, перекладывает байты. Там были самописные Make скрипты сборки. Каждому удавалось для новой платы написать прошивку за 2-3 недели. До этого я делал, то же самое в другой российском компании, но только в IAR. И в целом на разработку прошивки для одной такой же платы уходило 2-3 года.
IDE - это идеальный инструмент для растягивания разработки во времени. Пока идет разработка прошивки в IDE , там, глядишь, и ипотека выплатится.
Мы сравниваем тёплое с мягким, путаем причину и следствие. Профессионал одинаково быстро соберёт прошивку для перекладывания байт в любой IDE (или без неё), но в привычной среде - чуть быстрее. И если потребуется "этот ваш CI/DI настроить", то возьмёт наиболее подходящий для этого инструмент.
В стартапах собираются профессионалы, чтобы заработать деньги на какой-либо новой технологии. Слабые специалисты там не задерживаются, иначе стартап благополучно разваливается. А профи часто рождаются в мире линукса. Там знать Make, CMake, etc жизненно необходимо.
В типичной же русской компании многое зависит от корпоративной культуры (или её отсутствия). Люди работают за зарплату. Там обычно торопиться некуда, можно не спеша перекладывать байты годами. И в чём это делать - в ИАРе или в командной строке - совсем не важно.
Большая проблема всех IDE, как было вскользь отмечено в статье, это снижение необходимой квалификации программиста для выполнения конкретных задач. Прошивки создаются в калокубе как пирожки, а что там внутри, к сожалению мало кого волнует. Если пересадить этих чудо-программистов на чистый мейк - это принципиально ничего не изменит.
И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает.
Программировать в IDE c плагинами - это тоже, что лаптями щи хлебать.
Сборка прошивок плагинами Eclipse это характерный признак junior программистов.
При сборке через плагины, вам надо также вручную мышкой прописывать ключи для компоновщика . Например -lm для подключения математических функций (sin, log, cos).
Проблеме в том, что это надо проделывать для каждой отдельной сборки, даже если код у сборок общий. То есть опять происходит бессмысленное дублирование конфигов и лишняя работа.
Если в Вашем проекте тыща вариантов сборок - то make, без вариантов. Если нужна всего пара конфигов, debug + release - то почему бы и нет. Для конкретной задачи выбираем наиболее удобный инструмент
А одной сборки по хорошему никогда не бывает.
Для каждой электронной платы нужно как минимум пять сборок.
Вторичный Загрузчик , generic release, assembly test, mbr(первичный загрузчик), generic debug.
Вот и получается ,что надо сразу начинать разработку на основе самописных make скриптов, а не на этих ваших пресловутых ардинообрахных gui ide.
Если нужна всего пара конфигов, debug + release - то почему бы и нет.
Вы забыли упомянуть отдельные сборки для того чтобы гонять прошивку на отладочных платах от производителя микроконтроллера, пока ваше изделие находится в производстве. Это еще 2-3 сборки.
Для конкретной задачи выбираем наиболее удобный инструмент
Именно так! Если задача спустить разработку под откос, то смело выбираете GUI-IDE. Вариантов масса: Eclipse c плагинами, IAR, KEIL, Arduino IDE.
Если надо вести работу на результат пишите скрипты сборки сами на CMake или Make. А текстовый редактор берите какой хотите.
Совершенно верно! Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, Eclipse, IAR, KEIL etc. Кстати, в моей практике я не встречал проектов, убитых использованием "GUI-IDE". Обычно причина либо экономическая (изделие не нашло спроса), либо схемотехническая, либо устаревание и снятие с производства важных компонентов.
Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, Eclipse, IAR, KEIL etc.
Для того чтобы спустить разработку под откос достаточно превысить все мыслимые сроки разработки. И GUI IDE с этой задачей справляются на ура.
Профессионал одинаково быстро напишет программу в любой среде. Некомпетентный инженер легко спустит разработку под откос независимо от используемого инструмента. Проблема не в инструменте, проблема в людях.
Кажется, аргументы закончились, и обсуждение пошло по второму кругу... Засим откланиваюсь, всем удачного кодинга
Профессионал одинаково быстро напишет программу в любой среде.
Профессионалы как раз предпочитают сами скрипты сборки писать.
А работа в Arduino(образных) GUI-IDE c плагинами - это удел Jun(ов) и всяческой школоты.
Градация Навыков в Embedded Программировании
Засим откланиваюсь, всем удачного кодинга
Вот именно, что "кодинга" , а не программной инженерии.
Так как типичные User(ы) GUIневых IDE больше ни на, что не способны, кроме этого самого "кодинга".
Кодеры, а не программисты.
Засим откланиваюсь, всем удачного кодинга
Если проводить аналогии с атомной энергетикой то, сборка через GUI-IDE - это как реакторы на горизонтальных ТВЭЛах (сборках), а сборка из скриптов это реактор на вертикальных ТВЭЛах.
Горизонтальные реакторы неудобны, так как надо две точки подвеса ТВЭЛа при загрузке топлива. Плюс нужны дополнительные усилия, чтобы проталкивать стержни в активную зону. Потом стержень может расплавиться и застрять. Тогда хана.
Напротив вертикальные ТВЭЛы загружаются под действие силы тяжести и для транспортировке сборки нужна только одна точка подвеса. Расплавленные ТВЭЛы просто стекают в поддон.
Только тех кто умеет собирать программы из скриптов и можно считать программистами. Те кто пользуются ide это школота.
Скрипты сборки GNU make (или СMake) хороши тем, что в скриптах сборки вы всегда можете написать текстовые комментарии. Вы можете рядом с каждым ключом компилятора или опцией компоновщика явно указать себе и коллегам подсказку , что это значит и для чего нужно. Понимаете?..
Одновременно с этим в GUI-IDE нет возможности в GUI форме указать в сombo-box-e, что значит тот или иной ключ GCC . И это делает *.xml конфиг абсолютно нечитаемым.
Ленивые юзеры получают франкенштейнов.
Сборка прошивок плагинам в GUI-IDE - это такое же паллиативное решение, как попытки приклеить трофейный немецкий реактивный двигатели Jumo-004 на советский самолёт Як-3. Это банально не красиво и поэтому не летает как надо.
В программировании микроконтроллеров нет царских путей! Если одно вы сделали просто, то в другом будет тяжко. И наоборот. Закон сохранения сложности.
а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение.Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает.
Обычно при коллективной разработке прошивок общий процесс и инструментарий подстраивается под самого слабого разработчика. Условно в компаниях, где есть коллективная разработка за стандарт банально выбирают Eclipse с GCC плагинами или IAR или Keil.
Поэтому Коллективная разработка не сулит никакого профессионального развития.
а если они начнут писать make вручную, их проекты вообще перестанут собираться.
Посмотрите сами @MikeSmith (Основы по GNU Make
https://habr.com/ru/articles/748162/)
ничего сложного в make нет в помине.
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши.
Программировать в GUI-IDE (типа IAR, Keil плагины Eclipse) это как ездить на трёхколесном велосипеде.
Eclipse плагины собирают всё что лежит в папке. Как то что нужно так и то что не нужно. Это провоцируют путаницу и ошибки.
Странный пункт. Что там может быть "не нужно"? Если оно действительно не нужно, зачем оно там? Если не участвует в сборке, то парой-тройкой кликов добавляется в исключения.
Все проблемы сборки возникают от непонимания задач разработчика. Основная задача разработчика - автоматизировать рутинные операции для большей производительности. Если разработчик даже свою работу не в состоянии автоматизировать и упростить, начиная с изучения горячих клавиш, то ... ой!
Одна из следующих по критичности задача - обеспечение повторяемости результата. Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант. А плагины IDE могут вносить свои коллизии из-за разных версий и своей идеологии.
Используйте системы сборки как с общими настройками, так и частными под проект. Инструменты же тут могут быть разнообразные. Как говориться: "На вкус и цвет". Но даже с системами сборки не забывайте про макросы, шаблоны, bash/bat-скрипты и симлинки (в Windows они тоже есть), т.к. автоматизировать и оптимизировать можно, практически, до бесконечности.
Основная задача разработчика - автоматизировать рутинные операции для большей производительности.
Это скорее задача DevOps(а). Задача разработчика сделать продукт.
Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант
Очень даже вариант, если Вы определяете переменные окружения в make скриптах. Вот пояснение https://habr.com/ru/articles/798213/
В make нет таких строгих ограничений на длину переменной окружения как в CMD .
Для начала работы с микроконтроллерами эклипс с плагинами отличная вещь, можно сильно не заморачиваться на детали и работать с самим МК. Но в нормальной работе конечно нужно знать и делать все эти детали, чтобы как можно полнее контролировать процесс сборки. Короче выбирайте CMake или что-то подобное.
эклипс с плагинами отличная вещь, можно сильно не заморачиваться на детали и работать с самим МК.
Eclipse c плагинами также удобен, как вот эта ручка на Почте России.
Да, писать можно, если ни разу не пробовал что-то другое.
Многие пользуются Eclipse IDE только потому, что им нужна функция автоматического форматирования отступов в исходниках горячей кнопкой Ctrl+Shift+F.
И приводят это как первый и самый главный аргумент...
А утилит clang-format.exe или GNU indent они либо вообще не знают, либо пользоваться не умеют.
Почему Сборка с Помощью Есlipse GCC Плагинов — это Тупиковый Путь