Комментарии 15
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован 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.
Ну не отсортирован cproject, и чем это мешает?
diff одинаковых сборок достигает 99%
а если они начнут писать make вручную, их проекты вообще перестанут собираться.
make файл пишется один раз и слабо меняется со временем.
Причем make файл можно сгенерить из STMCubeMX.
И нажать F5 (refresh) ну ни разу не проблема.
Проблема, если у Вас сборки собирает Jenkins ( почитайте про CI / CD)
Eclipse плагины собирают всё что лежит в папке. Как то что нужно так и то что не нужно. Это провоцируют путаницу и ошибки.
Странный пункт. Что там может быть "не нужно"? Если оно действительно не нужно, зачем оно там? Если не участвует в сборке, то парой-тройкой кликов добавляется в исключения.
Все проблемы сборки возникают от непонимания задач разработчика. Основная задача разработчика - автоматизировать рутинные операции для большей производительности. Если разработчик даже свою работу не в состоянии автоматизировать и упростить, начиная с изучения горячих клавиш, то ... ой!
Одна из следующих по критичности задача - обеспечение повторяемости результата. Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант. А плагины IDE могут вносить свои коллизии из-за разных версий и своей идеологии.
Используйте системы сборки как с общими настройками, так и частными под проект. Инструменты же тут могут быть разнообразные. Как говориться: "На вкус и цвет". Но даже с системами сборки не забывайте про макросы, шаблоны, bash/bat-скрипты и симлинки (в Windows они тоже есть), т.к. автоматизировать и оптимизировать можно, практически, до бесконечности.
Основная задача разработчика - автоматизировать рутинные операции для большей производительности.
Это скорее задача DevOps(а). Задача разработчика сделать продукт.
Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант
Очень даже вариант, если Вы определяете переменные окружения в make скриптах. Вот пояснение https://habr.com/ru/articles/798213/
В make нет таких строгих ограничений на длину переменной окружения как в CMD .
Для начала работы с микроконтроллерами эклипс с плагинами отличная вещь, можно сильно не заморачиваться на детали и работать с самим МК. Но в нормальной работе конечно нужно знать и делать все эти детали, чтобы как можно полнее контролировать процесс сборки. Короче выбирайте CMake или что-то подобное.
Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь