uninstall mingw

Classic

List

Threaded

uninstall mingw

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: uninstall mingw

Pieter wrote:
> Everything worked fine, but I noticed that since I did that, some command
> line instructions didn’t work anymore. (e.g. ipconfig, ping, . )
> I do recall that once I removed the c:\MinGW\bin; from the PATH variable,
> everything worked fine again.
> But since I needed the gcc compiler I put it back (so I could work with
> gcc).

That’s real strange and sounds like something something went terribly
wrong there.
Could you perhaps post the entire contents of both your system PATH
variable and your user PATH variable?

> Does this sound familiar to someone, if so any help would be appreciated ?!
> Also, I didn’t find any subject on how to uninstall. (except that «remove
> package» doesn’t work yet ?)

Remove from path + delete all files.

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: uninstall mingw

First off, next time you may want to send your reply to the entire
list, not just to me. If you had, anyone would have been able to read
your PATH variable contents and suggest a solution based on them.
Sometimes there are moments when you want to reply to the person who
sent the mail rather than to the mailing list, but this was not one of
them.

Pieter wrote:
> system PATH variable:
>
> C:\watcom-1.3\binnt;C:\Program Files\MATLAB\R2009bruntime\win64;C:\Program
> Files\MATLAB\R2009b\bin;

You are clearly missing some paths in there. Looking at my windows
installation, the system directories you are missing are:
— %SystemRoot%\system32
— %SystemRoot%
— %SystemRoot%\System32\Wbem

However, these are in a windows XP x64 environment, they might be
slightly different in a different OS version. Perhaps someone system32
could check what his PATH variable holds?

Just for clarity, you would need to add these to you PATH variable (at
the beginning makes the most sense, but it doesn’t matter much where
you put them), separating each path from the next with a semicolon.

> I only have one «PATH» variable and it it listed under «system variables»,
> it’s the one above.

That doesn’t matter really, windows just uses the combination of both
— but you rarely want to use the user variable PATH, I just asked for
completeness.

> By the way, is there some sort of forum where the questions I sent appear,
> because I’m new to this mailing list concept and I find it rather confusing.

Как удалить mingw windows

Давайте разберемся, что такое MinGW, а что такое MSYS и для чего они нужны.

MinGW – сокращение от “Minimalist GNU for Windows”, по своей сути MinGW является небольшой и лаконичной средой разработки нативных приложений для семейства OS Microsoft Windows.

MinGW предоставляет полный набор Open Source инструментов для программирования, который подходит для разработки нативного Windows приложения, которое не будет зависеть от C-Runtime библиотек каких-либо третьих сторон.

MinGW поддерживает идею минимализма, поэтому он никогда не будет полностью поддерживать среду исполнения POSIX, для развертывания POSIX приложений на Windows, для их полной поддержки существует Cygwin. В первую очередь MinGW предназначен для использования разработчиками, которые привыкли работать с компилятором gcc.

MinGW включает в себя:

• Порт GNU Compiler Collection (GCC), который включает в себя компиляторы таких языков, как: C, C++, ADA и Fortran.
• Порт GNU Binutils для Windows (as, ld, ar)
• Консольный установщик (mingw-get) для MinGW и MSYS
• Графический установщик (mingw-get-inst)

MSYS – сокращение от “Minimal SYStem”, это порт командной оболочки Bourne Shell (sh) для Windows. Он предлагается в качестве альтернативы “cmd.exe” от Microsoft’а. Оболочка хорошо подходит для портирования существующих приложений и библиотек, которые есть в *nix системах и включает в себя небольшой выбор портов инструментов Unix, облегчающих задачу портирования.

Комбинация MinGW и MSYS предоставляет разработчикам небольшую независимую среду, которая может быть легко загружена на съемные носители, не требуя добавления записей в файлы реестра.

Далее набираем в консольном окне такие команды:

И в итоге получаем исполнительный файл “GLUT-Req.exe”. Обратите внимание на:

Без установки этих переменных CMake не видит библиотеку GLUT.

Из названий переменных все должно быть понятно:

Каталог с исходниками можно оставить в чистом состоянии. Для этого следует перейти в сборочный каталог (в данном случае “build_project”) и разверенуть в него дерево исходного кода с последующей генерацией Makefile’ов. Пример:

В аргумент “build” необходимо прописать путь до каталога с исходным кодом, который нужно оставить чистым. После выполнения команды в каталоге “build_project/” создастся полная копия дерева проекта и в этом каталоге можно будет выполнять дальнейшую сборку.

1.4.2.4. Кросскомпиляция с помощью CMake.

В папке с проектом создаем файл с расширением “.cmake”, например, “Toolchain-eldk-ppc74xx.cmake”, с подобным содержимым:

И конфигурируем проект:

Если переменная “CMAKE_FIND_ROOT_PATH_MODE_PROGRAM” установлена в NEVER, то будут использоваться инструменты из недр вашей системы. Если она установлена в ONLY, то будут использованы инструменты из каталога “CMAKE_FIND_ROOT_PATH/bin”. В этом случае следует быть осторожным, так как из поля видимости CMake пропадают некоторые кросс-утилиты из состава binutils, например tuple-ar и tuple-ranlib. Решить эту поблему можно с помощью создания симлинков на эти инструменты. Симлинки следует расположить в директорию “CMAKE_FIND_ROOT_PATH/bin”. В противном случае, при сборке проекта может возникать следующая ошибка:

Подробнее можно прочесть тут: CMake Cross Compiling

1.4.3 Что почитать про CMake? (литература):

Релиз CLion 2021.1: глобальный анализ потоков данных, улучшения для удаленной работы, постфиксное автодополнение

В JetBrains стартовал новый релизный год: все наши десктопные продукты обновились или обновятся в самое ближайшее время. Сегодня мы хотим поговорить о CLion 2021.1 — новейшей версии нашей кроссплатформенной IDE для разработки на C и C++.

В этом обновлении много яркого и интересного:

Глобальный анализ потоков данных

Новые проверки MISRA

Проекты Makefile в удаленном режиме

Динамический анализ в удаленном режиме

Инструмент для совместного редактирования кода

Улучшения для различных типов проектов (CMake, Makefile, Qt)

Постфиксное автодополнение для C и C++

Улучшения платформы IntelliJ и обновления плагинов

Новую версию можно скачать с нашего сайта и попробовать бесплатно в течение 30 дней. Если у вас есть активная подписка на CLion или All Products Pack, просто обновите версию на 2021.1. Напоминаем, что при покупке годовой подписки на любой продукт предоставляется резервная бессрочная лицензия.

А теперь поговорим о нововведениях и улучшениях в версии 2021.1 подробнее.

Анализатор кода

Глобальный анализ потоков данных

Анализ потоков данных — это мощный инструмент, который позволяет находить такие ошибки или потенциально проблемные места в вашем коде, которые не найдет компилятор. Ошибки висячих указателей (dangling pointer), разыменование нулевой ссылки (null dereferencing), неиспользуемый или недоступный код, бесконечные циклы и бесконечная рекурсия (это, кстати, не всегда ошибка, иногда такие вещи используются нарочно, но предупрежден — значит вооружен, как говорится) и многое другое.

Нам интересно реализовывать сложные инструменты анализа кода в наших продуктах — они помогают выявлять больше потенциальных проблем еще на стадии написания кода в редакторе. Анализ потоков данных (DFA) появился в CLion очень давно, а в 2020 году мы переписали его на Clang для увеличения производительности и точности анализа. В 2021 мы расширили и переработали анализатор, чтобы он поддерживал режим глобального анализа потоков данных. В чем разница между локальным и глобальным анализом?

Локальный анализ потоков данных работает в контексте тела функции и анализирует код только в нем. Такой анализ использовался в CLion до версии 2020.3 включительно.

Глобальный анализ потоков данных работает в контексте единицы трансляции (TU), позволяя увидеть более сложные связи и выявить больше проблем. Он появился только сейчас, в CLion 2021.1.

К примеру, некоторые висячие указатели можно выявить только в глобальном режиме:

Точно так же с разыменовыванием некоторых нулевых ссылок:

С появлением режима глобального анализа потоков данных также стали возможны новые проверки:

Постоянный результат функции — сообщает о функциях, возвращаемое значение которых всегда является одной и той же константой.

Постоянный параметр — сообщает о функциях, в которых параметр всегда является одной и той же константой.

Недостижимые вызовы функций — обнаруживает функции, точки вызова которых никогда не будут достигнуты.

Как часто бывает, пока мы обобщали анализ потоков данных и создавали глобальный режим, у нас произошло множество улучшений в самом алгоритме. Поэтому производительность не только не ухудшилась (чего можно было бы ожидать, так как теперь собирается и анализируется больше данных), но даже по некоторым параметрам улучшилась. Подробности и результаты наших измерений мы приводим в отдельном (англоязычном) посте.

Кстати, в качестве следующего улучшения анализатора кода мы планируем добавить Lifetime-проверки. Да-да, те самые из предложения Герба Саттера, и даже лучше!

Интеграция Clazy

Мы продолжаем улучшать поддержку Qt-проектов. Нет, поддержку QML из коробки пока не завезли 🙁 Но мы добавили в наш языковой движок на базе Clang интеграцию с Clazy — анализатором для кода Qt. В редакторе CLion теперь доступны соответствующие проверки кода и быстрые исправления:

Настройки анализатора можно найти в Settings/Preferences | Editor | Inspections | C/C++ | General | Clazy. Стоит обратить внимание на параметр level — уровень важности проверок Clazy. В данный момент CLion 2021.1 поддерживает версию CLazy 1.8.

Новые проверки MISRA

CLion поддерживает все больше проверок стандартов MISRA C 2012 и MISRA C++ 2008. До поддержки всех проверок нам пока далеко, однако вот полный список тех, которые мы уже поддержали.

Мы планируем поддержать все проверки стандартов MISRA и начать работу над стандартом AUTOSAR.

Смотрите видео об улучшениях встроенного анализатора кода от нашего девелопер-адвоката Фила Нэша:

Удаленная работа

Проекты Makefile в удаленном режиме

В CLion 2021.1 появилась базовая поддержка удаленного режима разработки для проектов Makefile. Чтобы воспользоваться ей, достаточно указать удаленный тулчейн в разделе Settings/Preferences | Build, Execution, Deployment | Makefile и перезагрузить проект.

Пока что самое большое ограничение — отсутствие поддержки шагов для преконфигурации. То есть работать все будет, только если в корне вашего проекта уже есть Makefile. Есть и другие ограничения.

Динамический анализ в удаленном режиме

Мы стремимся к единообразию возможностей IDE для всех тулчейнов, моделей проектов и конфигураций, и теперь Google Sanitizers, Valgrind Memcheck и анализ покрытия кода работают в том числе с удаленными тулчейнами. Кстати, что касается анализа покрытия кода, теперь вам также доступен анализ покрытия ветвей кода (в дополнению к анализу покрытия строчек).

Таким образом, в зависимости от используемого тулчейна CLion предлагает следующие метрики:

Покрытие строк кода (Line coverage) — то, что считает инструмент GCC/gcov. В частности, используя его, для строки return 0; int c; вы вполне можете получить покрытие 100%.

Покрытие выражений (Statement coverage) — то, что считает инструмент LLVM/llvm-cov. Здесь делается честный подсчет покрытия по выражениям, и для примера, приведенного выше, 100% вы не получите.

Покрытие ветвей кода (Branch coverage) — работает и в GCC/gcov, и в LLVM/llvm-cov с версии 12.0.0. Следует помнить, что GCC/gcov учитывает ветви, сгенерированные на этапе компиляции, а LLVM/llvm-cov — нет. Поэтому вы с трудом добьетесь от gcov покрытия 100% при наличии таких вот «‎скрытых веток»‎, возникающих, в частности, из-за обработки исключений.

Удаленный терминал

При работе с удаленным проектом порой возникает желание выполнить какую-то команду на удаленном хосте (в папке проекта). Разумеется, в CLion вы можете открыть ssh-сессию на удаленной машине. Однако если вы используете настройки по умолчанию, вам еще предстоит найти папку проекта (узнать путь, по которому IDE ее синхронизировала). Мы решили упростить эту процедуру. Новое действие Tools | Open Remote Host Terminal сразу переходит в папку проекта на удаленном хосте. Удаленный хост соответствует выбранному удаленному профилю, а локальный — первому удаленному профилю, найденному в проекте.

Инструмент для совместного редактирования кода

Code With Me — наш новый инструмент для совместной удаленной разработки и парного программирования. Мы про него уже писали в прошлый релиз, когда он только появился и был доступен по программе раннего доступа. Коротко об изменениях:

Сервис теперь доступен официально, программа раннего доступа завершена.

Соответствующий плагин включен в CLion 2021.1 по умолчанию.

О том, входит ли Code with Me в вашу подписку и какие мы предлагаем коммерческие планы, можно узнать на нашем сайте.

Все планы включают: аудио- и видеозвонки, поддержку совместного редактирования кода, режим полной синхронизации, умный анализ кода и многое другое.

И хотя пока не все возможности CLion доступны в режиме совместного редактирования, сервис уже умеет довольно много. Пробуйте и рассказывайте нам о своих впечатлениях!

Улучшения для различных типов проектов (CMake, Makefile, Qt)

Мы уже поговорили о поддержке проектов Makefile в режиме удаленной разработки и анализаторе Clazy для проектов на Qt. Но в CLion 2021.1 есть и другие улучшения для различных типов проектов.

CMake

Обновление включает версию CMake 3.19 (кстати, это первая версия, поддерживающая Apple Silicon — чип M1. Мы также успели поправить критическую проблему с версией CMake 3.20 — теперь ее тоже можно использовать в CLion 2021.1, но по умолчанию эта версия CMake пока не включена в поставку CLion.

Профили CMake, которые вы настраиваете через IDE, теперь можно сохранить в VCS. Для этого выберите опцию Share в разделе Settings/Preferences | Build, Execution, Deployment | CMake, после чего вы сможете закоммитить файл cmake.xml в систему контроля версий вместе с проектом. Предвосхищая вопрос из зала: поддержка CMake Presets будет, работа над ней начнется уже в ближайший релиз (CPP-22906).

Makefile

Основное обновление для проектов Makefile — начальная поддержка удаленных тулчейнов. Кроме того, мы встроили в CLion плагин Makefile Language, разработку которого наша команда также взяла на себя. Плагин обеспечивает подсветку синтаксиса make , быстрый доступ к документации, действие Find Usages для таргетов, а также различные возможности навигации и автодополнения кода для Makefile.

Помимо встроенного анализатора Clazy, разработчики Qt-проектов могут пользоваться обновленным диалогом создания нового класса — Qt UI Class:

Появилась возможность указать пространство имен и вписать произвольный класс в качестве родительского класса.

А еще мы добавили раскладку клавиатуры QtCreator.

Видео от Фила Нэша об улучшениях для различных типов проектов:

Постфиксное автодополнение для C и C++

Хотели ли вы иметь для языков C и C++ унифицированный синтаксис вызова функций (UFCS)? Теперь он вам не нужен! С новой возможностью постфиксного автодополнения кода на C и C++ вы сможете передать только что написанное выражение в свободную функцию в качестве первого аргумента. Введите выражение, поставьте точку и выберите свободную функцию из списка вариантов автодополнения:

С помощью постфиксного автодополнения также можно обернуть только что написанное выражение в одну из типичных языковых конструкций:

Среди шаблонов есть циклы, конструкции приведения типов и многое другое. Полный список вы найдете в разделе Settings/Preferences | Editor | General | Postfix Completion.

Видео от Фила Нэша с примерами того, насколько полезным может быть постфиксное автодополнение:

Отладчик

В этом обновлении мы доработали отладку дампов памяти:

В настройках конфигурации теперь можно указать sysroot. Это поможет находить библиотечные символы при отладке дампов приложений, собранных в других системах.

Для LLDB теперь возможна отладка дампа памяти приложений, собранных без отладочной информации, если эта информация отдельно указана в настройках отладчика (в виде файла символов). Раньше это работало только для GDB, а теперь доступно и для пользователей LLDB.

Действие Set Execution Point теперь работает не только для кода на C/C++, но и для ассемблерного кода:

Рекомендуем использовать это действие с осторожностью. Например, важно не пропустить шаг инициализации переменных.

Улучшения платформы IntelliJ и обновления плагинов

Множество улучшений «приезжает» в CLion из платформы IntelliJ. Например, те, что связаны с системами контроля версий:

Возможность выбирать профиль инспекций кода, которые запускаются перед коммитом

Действие Save to Shelf и др.

А еще CLion очень популярен среди Rust-разработчиков. И в плагине IntelliJ Rust мы тоже добавили множество улучшений — про них мы выпустили отдельный пост в нашем англоязычном блоге. Скажем лишь коротко, что мы добавили рефакторинг Change Signature и улучшили поддержку условной компиляции, а действие Find Usages теперь доступно для функций Cargo.

Также хочется упомянуть плагин для поддержки языка Swift. Вы спросите: “Зачем это нужно в CLion, когда есть AppCode!?” Да, но AppCode доступен только для Mac, а Swift теперь работает и на Ubuntu, и на Windows. Поддержка Swift на платформе Windows — это именно то, что мы добавили. Всю работу проделали наши коллеги из продукта AppCode. А если вам интересно, как же начать программировать на Swift под Windows, читайте пост в блоге Appcode.

На этом у нас все. Если вы дочитали до конца, напишите в комментариях свое любимое сочетание клавиш в CLion, если таковое имеется.

Спасибо за внимание! Оставляйте ваши вопросы, мысли и предложения в комментариях — нам интересно, что вы думаете, и мы всегда рады помочь!

Команда CLion
The Drive to Develop

Похожие публикации

Финальный релиз этого года — CLion 2020.3! С новыми функциями в отладчике, проверками MISRA и улучшениями для Qt

CLion 2020.2: поддержка проектной модели Makefile, больше C++20 и не только

CLion 2019.3 уже здесь! Повышенное быстродействие редактора и самые долгожданные новые возможности

Вакансии компании JetBrains

Комментарии 44

В IntelliJ IDEA и CLion сплеши на темном фоне. Сделали чуть менее контрастными как раз по просьбам пользователей. Но вообще передадим ваш фидбек команде дизайна. Спасибо!

У нас нет понятия 2021 мажорного релиза. Мажорных релизов — 3 в год (2021.1, 2021.2, 2021.3). Минорные апдейты (со второй точкой) с баг-фиксами доступны по «вечной лицензии» на ту версию, с которой начался годовой период оплаты.

А можете сказать конкретнее, какие именно баги особенно мешают и какой важный функционал отсутствует?

Тикеты в YouTrack я, безусловно, смотрю, как и читаю весь фидбек по всем соц. каналам наших продуктов. Комментарий не очень вежливый с вашей стороны.

Но если оставить ваш уровень токсичности в стороне, то давайте разбираться по пунктам. Соб-но, конкретные проблемы я спрашивала чтобы как-то посмотреть, какие у нас планы и можем ли мы что-то приоритизировать из важного вам. Ведь бывает так, что задача лежит, но с низким приоритетом, потому что про нее особо никто не спрашивает.

«Кучу багов WSL, mingw-w64 с WSL не поддерживался» — на WSL много всяких задачек, но наверное самое критичное это определение самого WSL. Вообще вся технология довольно молодая, и MS часто и много там всего меняет прямо в основании, да и багов там тоже много. WSL и WSL2, например, совсем разные системы. Поэтому определение, к сожалению, пока не очень стабильно. Остальное из мне известного — этого какие-то штуки, которые иногда не стабильно работают в случае с WSL из-за особенностей маппинга данных или чего-то такого. Если что-то из такого особо мешает, скажите, мы посмотрим, что можно сделать. Про mingw-w64 я, к сожалению, не поняла, потому что на WSL же линуксовый тулчейн.

«даже QT поддерживается криво, кучу ошибок сыпет по синтаксису, часть видимо пофиксили в 2021.1» — вообще подсчетка кода и показ ошибок через Clangd гарантирует, что корректно компилирующийся код мы подсветим без ошибок. Какая-то специфика Qt может не учитываться при автогенерации кода, но это другая история. По трекеру есть вот такая задача CPP-14377, но автор ее нам так и не ответил, а у нас не воспроизвелось. Если у вас воспроизводится проблема, пожалуйста, отпишитесь в задаче.

«Нет профилировщика GPU, графических элементов.» — было бы наверное и вправду интересно что-то такое добавить. Надо изучать существующие инструменты для начала, конечно. Создала реквест к нам CPP-24788.

«нет в отладчике смены отображения данных для базовых типов» — вообще hex-view есть (вот тут написано, как его включать). Мы его называем «экспериментальным» только потому, что нам не очень нравится, как именно он работает. Хочется переписать и это даже есть в планах у подкоманды отладчика, но пока отвлекают более приоритетные задачи.

«даже нет базовой подсветки синтаксиса VHDL» — не самый популярный запрос к нам, признаюсь често, но некоторый экспериментальный плагин у нас есть. Узнаю, что там с публичным доступом к нему.

«Embedded поддержка тоже не полноценная, ни xilinx ни stm32, нормально не поддерживаются» — а что все же такое «нормальная поддержка»? Текущая поддержка описана вот тут. Она, конечно, сильно не полная — мы только недавно начали двигаться в эту сторону. Думаю, Elmot будет очень интересно послушать ваши идеи.

реиндексирование — это явная проблема, ее стоит заводить в трекер.

Про Rider отвечу позже, обсужу с командой.

Не понятно зачем покупать ради QT Clion если есть нормальная native поддержка в Qt Creator.

Конечно, незачем. Но тем, кто для Qt разработки использует CLion, это может быть полезно. Соб-но, запрос пришел от таких пользователей.

1. mingw генерирует более быстрый код. Когда я писал быстрый аналог protobuf, то версия на mingw генерировала значительно более быстрый асинхронный многопоточный код чем MSVC. Но под виндовс сборки mingw кривоватые, устаревшие и генерировали файл в 2 раза больше. Самая последняя сборка есть в Arch Linux и с ней полноценно можно компилировать виндовые приложения. Arch Linux можно поставить в WSL, но проблема в clion была, что он вроде кроме как с убунтой нормально ни с кем не дружил, и не стандартные диструбитвы не видит. WSL приложения можно выполнять как консольные команды, если прописать пути к файлам mingw то тоже какой-то глюк был, уже не помню. Если с помощью хака запускать в WSL SSH сервер, то так же не возможна отладка на виндов и сборка в WSL. Если запускать clion под Arch Linux, то в arch linux cmake опережает поддерживаемую вами версию, у меня выходит данная версия CMAKE не поддерживается. cmake version 3.20.1 В Arch есть специальный пакет aur.archlinux.org/packages/mingw-w64-cmake который устанавливает пути и окружения для сборки в mingw, но этот cmake нельзя указать, он не поддерживается. Можно сделать хак и создать toolchain файл и загрузить его с помощью -DCMAKE_TOOLCHAIN_FILE во встроенный в clion cmake pastebin.com/qiUPnhm6, тогда можно успешно компилировать. Так как путь к toolchain файлу длинный, его не удобно вписывать в параметры, он мешает их редактировать и смотреть, поэтому есть предложение добавить соответствующее поле где можно указать путь к тулчаин, так как например указывается путь к cmake, gdb, gcc, g++ и т.д. Про путь к тулчаин вроде еще много лет писал на вашем YouTrack.

2. Сыровата поддержка, хоть вас просили добавить поддержку QT, она еще сырая.

5. VHDL если бы поддерживался и с ним было бы удобно работать, то было бы хорошо это плюс к Embedded. И было бы хорошо, если можно было бы заменить Xilinx Vitis. Как видится мне Embedded это направление, где CLion может взять себе долю рынка, особено с поддержкой MISRA. Для десктоп приложений есть QT, Visual Studio, Embarcadero, XCode с визуальным редактором и набором компонентов, к пример Embarcadero стоит значительно дороже, но там релизы более стабильные и поддержка лучше. Плагин VHDL не очень интересен, так как банально нет даже симуляции, например даже в matlab она есть.

6. Были большие надежды, что ошибался, но вот достал свою плату на h745zi-q от ST, пол дня промучался пытался открыть и создать проект проекты по разному, посмотрел документацию, но пропустил один момент, что там есть приписка 745 не поддерживается, видимо все многоядерные чипы не поддерживаются, а судя по ссылки plugins.jetbrains.com/plugin/10115-openocd—stm32cubemx-support-for-arm-embedded-development/versions/stable на модуль поддержка только в альфа режиме и не особо он развивается, ссылка с вашей документации. А ведь так хотелось, что бы можно было заменить stm32ide. В первую очередь загрузка прошивки, и удаленная отладка. Еще одним пунктом было бы хорошо иметь возможность собирать загрузочные образы, как в Xilinx Vitis. Вообще пока очень сырая поддержка.

В Rider была отписка, что все это проприетарное и макрософт не делится, поэтому поддержка проблемная. Сейчас не знаю как обстоят дела, у меня сейчас основная система для программирования Arch Linux, и под виндовс ставить тулчеин не очень охото проверерять.

Простите за резкость, я всегда прямолинеен, нравится вам или нет, но вот я нигде не слукавил и написал главные недостатки продуктов jetbtains. Надо много дорабатывать, чтобы IDE стали более самостоятельными и полноценными, а то получается поддержка Embedded в Clion хуже чем в arduion ide.

• лучше использовать mingw-w64, чем просто mingw
• то, что вы описываете про WSL, это поддержка кастомных дистрибутивов, не из маркетплейса виндового — это сейчас в работе как раз, будет видимо в 2021.2
• cmake version 3.20.1 использовать можно. Мы пишем, что поддерживаем официально версии до 3.19, так как мы с ними протестировались, поддержали какие-то фичи, проверили, что точно все гладко работает. Но для 3.20 мы вроже критичные баги тоже в этом релизе поправили и пока других не видим — так что можно брать.

Про Qt: «сыровата» это, к сожалению, не очень критерий. Говорите, что плохо, мы посмотрим. Так иначе не понятно, что улучшать.