Как запускать C++ файлы без конфликтов в Clion
Я скачал Clion недавно. Я создал два .cpp файла с простым кодом (оба кода работают по отдельности верно). Но проблема в том что Clion не может просто так компилировать несколько файлов которые используют main (я имею ввиду если написать в обоих файлах int main() <. . .>и int main() <. . .>то при компиляции любого из этих файлов выдаст ошибку). Как это исправить? Ошибка:
duplicate symbol '_main' in: CMakeFiles/CodeForces.dir/158A.cpp.o CMakeFiles/CodeForces.dir/4A.cpp.o ld: 1 duplicate symbol for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Отслеживать
задан 6 мар 2022 в 16:10
user18279824 user18279824
создавайте отдельные проекты. Они для этого и предназначены. А просто «запустить файл» — так оно не умеет. Хотите «запускать» каждый файл по отдельности — делайте это с консоли.
6 мар 2022 в 16:23
Точка входа в приложение main в каждом исполняемом файле должна быть только одна. Соответственно вам следует для каждого файла создать цель — исполняемый файл посредством add_executable .
Как работать с Makefile-проектами в среде CLion
За последние несколько лет мне пришлось столкнуться с множеством вопросов, которые были сформулированы примерно так: «мой проект не открывается в среде CLion». В свою очередь, это приводило к необходимости из раза в раз объяснять разным людям примерно одно и то же. Статья имеет целью сохранить тот опыт, который был накоплен в процессе анализа десятков разных проектов. Предполагается, что официальная документация вам уже известна и не вызывает вопросов.
Если вам лень вникать в скучные технические детали, можете перейти прямо к разделу «Рекомендации».
Постановка задачи
Основная проблема с проектами, использующими в качестве системы сборки Make, состоит в том, что эта система не предоставляет ровным счётом никакой информации о проектной модели, т. е. о том, какие файлы исходного кода попадут на вход компилятора, какие ключи компилятора, директивы препроцессора и заголовочные файлы будут использованы, и какие бинарные файлы мы получим на выходе. Эта информация остаётся неизвестной до тех пор, пока проект не будет собран. В этом состоит сложность задачи интеграции сред разработки (IDE) и системы сборки Make.
Рассмотрим, например, проект с вот такой плоской структурой:
и вот таким элементарным Makefile :
.PHONY: all all: foo .PHONY: clean clean: $(RM) fooЗдесь видно, что файл foo.c является частью проектной модели, т. к. будет участвовать в процессе компиляции (посредством встроенного правила $(CC) foo.c -o foo ), а файл bar.c — не является.
Подходы к анализу проектной модели
База данных компиляции
Можно решить задачу «в лоб» и сначала собрать проект, а уж затем выяснить, какие файлы и с какими флагами были скомпилированы. Для создания файла compile_commands.json (собственно базы данных компиляции) будем использовать любой из доступных генераторов — bear или compiledb . bear работает посредством перехвата динамических вызовов ( LD_PRELOAD ) и потому выдаёт достаточно точный результат, не зависит от системы сборки (т. е. может использоваться совместно с любой системой сборки, хоть с чёртом в ступе, а не только с Make), но имеет ограничения на Mac OS X и вообще не работает на Windows. С другой стороны, compiledb анализирует исключительно вывод команды make и потому нередко совершает ошибки, но, с другой стороны, работает везде. Если вы используете Linux, я предлагаю вам остановить свой выбор именно на bear . По крайней мере, у вас не будет ошибок, связанных с неверной интерпретацией двойных кавычек, апострофов и путей, содержащих пробелы.
Итак, мы собрали наш проект, «обернув» команду сборки и выполнив что-то вроде bear make или bear make all , и теперь имеем на выходе заветный compile_commands.json . CLion вполне в состоянии открыть этот файл как проект, но у такого подхода есть по меньшей мере 2 недостатка:
- Сборка всего проекта может занимать десятки минут (ядро Linux) или даже часы, а открыть проект в IDE хочется «почти мгновенно».
- Если вы не просто открыли проект с целью «посмотреть код», а собираетесь добавлять/удалять/переименовывать файлы, переписывать сам Makefile или его прототип (как в системах сборки типа GNU Autotools, работающих поверх Make), то после каждой такой операции вам придётся заново генерировать базу данных компиляции. И это муторно, скажу я вам.
Поэтому стоит задаться вопросом, нет ли способа проанализировать структуру проекта, не выполняя сборку.
Переопределение переменных окружения
Переопределение переменной $(MAKE)
Этот подход не может использоваться как самостоятельное решение, однако, если проект использует рекурсивные вызовы Make (см. 5.7 Recursive Use of make ), можно переопределить переменную MAKE и, подставив в значение путь до собственной «обёртки» над Make ( MAKE=my-custom-make-wrapper ), отслеживать все такие вызовы и, при необходимости, менять или дополнять флаги Make, редактируя аргументы перехватываемой командной строки.
Переопределение компиляторов
Переопределяя переменные CC и CXX (и имея «обёртку», которая может имитировать поведение компилятора), можно перехватывать вызовы компилятора и, таким образом, точно знать, в каком каталоге и с какими аргументами компилятор был вызван.
Переопределение оболочки
Переопределяя переменную SHELL (при наличии «обёртки», опять же), можно получить информацию обо всех вызываемых командах (а не только о командах компиляции).
Разумеется, вышеупомянутые техники можно произвольным образом комбинировать.
Перехват системных вызовов
На Linux, Solaris и, с оговорками, Mac OS X информацию о системных вызовах execve() (и интересующих нас аналогах) можно получить через механизм LD_PRELOAD или (Linux) запуская утилиту strace . Впрочем, полученное решение уже не будет кроссплатформенным.
Мне не известен ни один инструмент, где бы хотя бы частично были реализованы эти техники, кроме, быть может, NetBeans CND и Oracle Solaris Studio. Однако, насколько мне известно, поддержка Makefile -проектов в упомянутых продуктах не развивалась с 2016 года.
Запуск Make в режиме «dry run»
На русский язык переводится как «репетиция», но подобного русскоязычного термина попросту нет, поэтому впредь будем называть этот режим именно «dry run», как в англоязычной документации. Вот описание ключа командной строки GNU Make:
Print the commands that would be executed, but do not execute them (except in certain circumstances).
Помимо этого флага, нам ещё понадобится флаг w :
Print a message containing the working directory before and after other processing. This may be useful for tracking down errors from complicated nests of recursive make commands.
Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same.
Полная командная строка, таким образом, будет make -wnk , и вывод команды Make в большинстве случаев позволяет нам проанализировать структуру проекта. Этот способ не столь точен, как переопределение переменных или перехват системных вызовов, но он относительно прост в реализации, и в CLion используется именно этот подход.
Вручную указывать в настройках проекта флаги w , n и k не нужно: в процессе анализа проектной модели CLion подставит их автоматически. При необходимости глобальные значения флагов, используемых для анализа, можно изменить в расширенных настройках, но доля проектов, где в этом была бы практическая необходимость, исчезающе мала:
Выделение списка целей
Помимо анализа проектной модели, CLion умеет собирать информацию о том, какие цели объявлены в Makefile . Каждая выявленная цель автоматически становится конфигурацией типа Makefile Application:
GNU Make
Для GNU Make информация о целях собирается так же, как это сделано в соответствующем сценарии из проекта bash-completion, достаточно воспользоваться флагом p :
Print the data base (rules and variable values) that results from reading the makefiles; then execute as usual or as otherwise specified. This also prints the version information given by the -v switch. To print the data base without trying to remake any files, use make -p -f/dev/null .
и выполнить make -npq .
BSD Make
Здесь нужен другой подход: BSD Make ничего не знает о флаге p , это расширение GNU.
В настоящее время CLion не поддерживает BSD Make, но, чисто теоретически, «научить» работать с целями BSD Make достаточно просто, используя (опять же, нестандартный) флаг V :
Print bmake ‘s idea of the value of variable, in the global context. Do not build any targets. Multiple instances of this option may be specified; the variables will be printed one per line, with a blank line for each null or undefined variable. If variable contains a ‘$’ then the value will be expanded before printing.
Таким образом, список целей можно легко получить, выполнив команду
bmake -V '$(.ALLTARGETS)'Если хочется исключить из этого списка синтетические «псевдоцели» ( .WAIT ), команду надо привести к следующему виду:
bmake -V '$(.ALLTARGETS:N.WAIT_*:O)'Рекомендации
Теперь, собственно, то, ради чего вся статья и была написана. Следование этим рекомендациям не даст стопроцентной гарантии, что ваш проект без ошибок откроется в CLion, но, во всяком случае, существенно снизит количество этих ошибок.
Часть советов касается рекурсивных вызовов Make. Внимательный читатель, вероятно, скажет, что это абсолютное зло, сославшись на статью Питера Миллера «Recursive Make Considered Harmful» (HTML, PDF). На что можно возразить, что подавляющее большинство проектов, основанных на GNU Autotools, таки использует рекурсию Make, так что зло это хоть и абсолютное, но, увы, неизбежное. К тому же, как выяснилось в процессе подготовки статьи, есть и альтернативный взгляд на вещи.
- Убедитесь, что проект таки собирается (в том же окружении и тем же компилятором, какие выбраны в настройках проекта CLion). Условно говоря, если в настройках выбраны WSL и GCC, то код должен собираться в выбранной гостевой виртуальной машине компилятором GCC. Отсутствующие заголовочные файлы, недостающие зависимости, завершающийся с ошибкой сценарий configure (для GNU Autotools) — все эти проблемы стоит разрешить заранее, до того, как вы попытаетесь открыть проект в CLion.
- Используйте GNU Make. Убедитесь, что путь именно к этому инструменту выбран у вас в настройках. POSIX Make, BSD Make, Borland Make и Microsoft NMake пока не поддерживаются.
- Если ваш Makefile использует рекурсивные вызовы Make, в коде рецепта (т. е. интерпретируемого оболочкой набора команд для сборки цели) всегда вызывайте $(MAKE) вместо make . Тому есть две причины.
Первая причина никак не связана собственно с CLion: у кого-то из пользователей инструмент Make может отсутствовать в переменной PATH или быть установлен как gmake или bmake . Рекурсивно вызывая $(MAKE) , вы можете быть уверены, что для родительского и дочернего процессов Make будет использован один и тот же исполняемый файл (напр., /usr/bin/make ), т. е., скажем, GNU Make никогда не породит BSD Make, и наоборот.
Во-вторых, в пресловутом режиме «dry run», используемом для анализа проектной модели, первая форма записи будет распознана как рекурсивный вызов с печатью соответствующих команд, а вторая — нет. Рассмотрим проект с такой структурой:- Makefile
- foo/
- Makefile
- foo.c
- bar/
- Makefile
- bar.c
А теперь сравним два варианта вывода Make. Первый, через $(MAKE) :
make: Entering directory '/home/alice' make -C foo all make[1]: Entering directory '/home/alice/foo' echo "Making all in foo. " gcc -c -o foo.o foo.c make[1]: Leaving directory '/home/alice/foo' make -C bar all make[1]: Entering directory '/home/alice/bar' echo "Making all in bar. " gcc -c -o bar.o bar.c make[1]: Leaving directory '/home/alice/bar' make: Leaving directory '/home/alice'make: Entering directory '/home/alice' make -C foo all make -C bar all make: Leaving directory '/home/alice'Во втором случае, если в каком-то из дочерних (рекурсивно вызываемых) Makefile ‘ов был столь нужный нам вызов компилятора, мы этого просто не увидим.
Кстати, ровно в вышеописанном нюансе состоит сложность реализации поддержки средой CLion инструмента BSD Make: с точки зрения конечного пользователя, bmake -wnk никогда не распознаёт рекурсивные вызовы, независимо от формы записи. Связано это с тем, что GNU Make в режиме «dry-run» ( -n ) для каждого рекурсивного исполнения $(MAKE) производит системный вызов execve() (тоже с флагом -n , разумеется), а вот BSD Make — как раз нет (разница легко обнаруживается при запуске утилиты strace с ключом -f ):
$ strace -f -e execve make -wnk 2>&1 >/dev/null | grep -vF ENOENT | grep -F execve execve("/usr/bin/make", ["make", "-wnk"], 0x7ffe8a5a35a0 /* 80 vars */) = 0 [pid 15729] execve("/usr/bin/make", ["make", "-C", "foo", "all"], 0x5608f4544a30 /* 84 vars */) = 0 [pid 15730] execve("/usr/bin/make", ["make", "-C", "bar", "all"], 0x5608f4544a30 /* 84 vars */) = 0 $ strace -f -e execve bmake -wnk 2>&1 >/dev/null | grep -vF ENOENT | grep -F execve execve("/usr/bin/bmake", ["bmake", "-wnk"], 0x7ffc10221bb0 /* 80 vars */) = 0foo.o: foo.c cc -c -o $@ $Вот так хорошо:
foo.o: foo.c $(CC) -c -o $@ $GNUMAKEFLAGS += --no-print-directoryВ качестве альтернативы, если вы работаете с "чужим" проектом, куда у вас нет прав на запись (пусть, напр., Node.js), и не хотите менять файлы, находящиеся под контролем системы VCS, можно для фазы анализа включить флаг e :
Give variables taken from the environment precedence over variables from makefiles.
Вот так могут выглядеть настройки проекта для Node.js:
Включение флага e через поле "Arguments" может быть альтернативным решением и в иных случаях, когда на уровне Makefile переопределены флаги Make или другие стандартные переменные окружения (см. ниже).
Избегайте параллелизма на уровне процессов ( make -jN при N > 1), "зашитого" в Makefile через переопределение переменных MFLAGS , MAKEFLAGS или GNUMAKEFLAGS (подробнее в 5.7.3 Communicating Options to a Sub-make ):
MAKEFLAGS += j8 .PHONY: all all: foo-all bar-all .PHONY: foo-all foo-all: $(MAKE) -C foo all .PHONY: bar-all bar-all: $(MAKE) -C bar allВ таких условиях Make будет использовать более одного (в примере выше — 8) параллельного процесса при рекурсивных вызовах, в результате чего в выводе команды сообщения вида "Entering directory '. '" и "Leaving directory '. '" будут перемешаны между собой, команды компиляции — произвольным образом разбросаны между этими сообщениями, и CLion не сможет отследить ни смену каталога, ни принадлежность команды тому или иному каталогу:
make: Entering directory '/home/alice' make -C foo all make -C bar all make[1]: Entering directory '/home/alice/foo' make[1]: Entering directory '/home/alice/bar' echo "Making all in foo. " make[1]: Leaving directory '/home/alice/foo' echo "Making all in bar. " make[1]: Leaving directory '/home/alice/bar' make: Leaving directory '/home/alice'
С учётом вышесказанного, если вы хотите иметь возможность собирать проект, используя несколько параллельных процессов Make, передайте флаг -j через поле "Build options" в настройках проекта (но ни в коем случае не через поле "Arguments" — флаги в этом поле используются для анализа проектной модели, но не для сборки):
Аналогичным образом, при рекурсивных вызовах Make, не переопределяйте региональные настройки ( LC_* , LANG , LANGUAGE ) внутри ваших Makefile 'ов и/или сценариев сборки. Дело в том, что CLion, отслеживая сообщения о смене каталога, ожидает эти сообщения именно на английском языке (и заботливо устанавливает нужное окружение для родительского процесса Make). Вот что будет, если вмешается пользователь:
export LC_ALL = ru_RU.UTF-8 export LANG = ru_RU.UTF-8 .PHONY: all all: foo-all bar-all .PHONY: foo-all foo-all: $(MAKE) -C foo all .PHONY: bar-all bar-all: $(MAKE) -C bar allВывод команды make -wnk :
make: Entering directory '/home/alice' make -C foo all make[1]: вход в каталог «/home/alice/foo» echo "Making all in foo. " make[1]: выход из каталога «/home/alice/foo» make -C bar all make[1]: вход в каталог «/home/alice/bar» echo "Making all in bar. " make[1]: выход из каталога «/home/alice/bar» make: Leaving directory '/home/alice'target: cd subdir && $(MAKE) targetиспользовать форму
target: $(MAKE) -C subdir target- Makefile
- foo/
- Makefile
- Makefile
- Makefile
и вот таким Makefile 'ом в корневом каталоге проекта:
all-recursive: for subdir in foo bar baz; \ do (cd $$subdir; $(MAKE) all) || exit 1; doneЗдесь рецепт цели all-recursive — это цикл оболочки POSIX, который, скорее всего, не будет выполнен в режиме "dry run". Если воспользоваться функцией $(foreach) , то можно переписать так:
all-recursive: $(foreach subdir,$(SUBDIRS),$(MAKE) -C $(subdir) all;)all: $(CC) -c *.cЕсли в одном с Makefile 'ом каталоге находятся, например, файлы foo.c и bar.c , то на стадии анализа команда make -wnk по-прежнему выведет
cc -c *.cа CLion не умеет вычислять маски оболочки (к тому же, на UNIX и Windows оболочки разные и, соответственно, синтаксис масок слегка различен). Вот так хорошо:
all: $(CC) -c $(wildcard *.c)В этом случае значение маски будет вычислено средствами Make:
cc -c foo.c bar.cmain.o: main.cpp $(CXX) -I../ -g -Wall $(shell pkg-config some-library) -c -o $@ $в то время как такой — нет:
main.o: main.cpp $(CXX) -I../ -g -Wall `pkg-config some-library` -c -o $@ $< $(CXX) -I../ -g -Wall $$(pkg-config some-library) -c -o $@ $На этом всё. Надеюсь, описанный опыт был кому-то полезен. Есть ещё некоторые нюансы, которые проще всего проиллюстрировать на конкретном Makefile -проекте (а именно, ядре Linux), но об этом — в следующей статье.
Как настроить CLion актуальной версии для запуска и компиляции
При кодировании C L ion позволяет ва м вообще забыть о рутине. Компилятор и отладка кода в C L ion просто на высоте. Вы можете четко сконцентрироваться только на важном, а все остальное этот редактор возьмет на себя. Данная IDE способна повысить в ашу производительность за счет «умного» и своевременного автозавершения кода, мгновенной навигации по документу и надежного рефакторинга.
Преимущества C L ion перед другими IDE
- Легкий старт. В данной IDE очень легко начать новый проект , ф айлы могут быть добавлены в проект одним щелчком мыши.
- Умный редактор. Благодаря своей умной среде, C L ion анализирует ваш код, понимает ваш проект и старается увеличить вашу скорость написания кода за счет интеллектуального автозавершения.
- Навигация и поиск. Найти необходимый «кусок» кода не составит труда — мгновенная навигация по символу, классу или файлу в этом помогает.
- Генерация кода и рефакторинг. C L ion экономит вам время за счет генерации кода — от геттеров/сеттеров до более сложных шаблонов.
- Анализ кода на лету. У вас есть возможность писать красивый и правильный код. Данная IDE «на лету» проводит статический анализ вашего кода для поддерживаемых языков , п оэтому она способна сразу показывать вам предупреждения и ошибки.
- Настройка редактора. Гибкая система настройки C L ion позволяет выбирать тему редактора, раскладку клавиатуры и др. В общем , позволяет вам полностью настроить C L ion под себя.
- Запуск и отладка C L ion. Вы можете запускать и отлаживать свою программу как локально, так и удаленно.
- Динамический анализ. Если использовать интеграцию с Valgrid Memcheck, Google Sanitizerz и CPU Profiler, то можно легко обнаружить ошибки в памяти, скачки данных и любую другую проблему, также можно с легкостью отслеживать производительность вашей программы.
- Поддержка CMake. CMake — это кроссплатформенная система сборки, которая широко используется для проектов С и С++.
- Модульное тестирование. CLion поддерживает платформы Google Test, Boost.Test и Catch. Также он имеет встроенный инструмент для запуска тестов.
- Документация по коду. В CLion легко документировать свой код. Доступен предварительный просмотр документов в стиле Doxygen во всплывающем окне.
- Встроенная разработка. В CLion вы легко можете разрабатывать для микроконтроллеров, используя различные возможности отладки.
- Интеграция VCS. Данная IDE предоставляет унифицированный интерфей с для большинства популярных VCS, таких как Git, GitHub, CVS, Perforce и другие.
- Удобный терминал. Вы легко можете получить доступ к командной строке через встроенный терминал, можете включить режим эмуляции Vim, можете расширить функциональность среды и другими плагинами.
Как настроить IDE CLion?
- Тема редактора. В настройках редактора есть возможность выбрать между светлой и темной темой оформления. Разработчикам с дальтонизмом можно попробовать параметр «Корректировать цвета красно-зеленого дефицита».
- Цвета и шрифты. Не стесняйтесь использовать настройки на полную. Вы свободно можете настроить макет цветов , шрифтов и синтаксиса, выделения ошибок, отладчика и т.д. Можете использовать предустановленные схемы цветов или созда ть с нуля сво и .
- Комбинации клавиш. IDE CLion по умолчанию предоставляет комбинации клавиш почти для каждой функции. Вы можете выбрать из списка подготовленных схем комбинаций или создать сво и .
- Фон редактора. Вы можете оживить редактор этой рабочей среды, установив любое фоновое изображение.
- Лигатуры. Если вам нравятся шрифты с лигатурами — используйте их.
- Семантическое выделение. Возможно , вам будет полезным способность настроить выделение каждой переменной или параметра своим цветом.
Запуск и отладка CLion
В зависимости от цели вашего проекта (CMake, Makefile, Gradle) CLion будет генерировать необходимую конфигурацию, которую можно будет запустить.
Запуск CLion
- Шаблоны конфигурации. Чтобы сократить время, вы можете использовать шаблоны конфигурации для модульного тестирования, удаленной отладки, запуска обычного приложения и т.д.
- Конфигурация запуска. Вы можете изменять исполняемый файл любой конфигурации. При желании можете сделать конфигурацию «не рабочей».
- Конфигурация отладки. Для старта отладки нужно нажать «Shift+F9». Чтобы проверить состояние отладки , CLion предоставляет много полезных ярлыков.
Отладка CLion
- Присоединение к локальному процессу. CLion позволяет отлаживать процессы на локальном компьютере, запускаемые на самом ПК, а не через IDE.
- Удаленная отладка GDB. Если у вас есть один запущенный исполняемый файл на локальном ПК под gdbserver, вы можете подключиться к нему с другого компьютера при помощи GDB из CLion.
- Контрольные точки. При старте отладки данная IDE может проверить выполнение вашего кода. Вы можете выбрать из нескольких точек останова (точки останова на стоке, символические точки останова, точки останова на исключение).
- Точки выполнения. С помощью действия Set Execution Point to Cursor вы можете перемещаться вперед/назад в процессе выполнения отладки, вы можете прерывать или перезапускать циклы и др.
- Отладка root. CLion может запускать и отлаживать вашу программу с правами root, если вы выберете эту опцию.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Подключение компилятора ARM GCC к CLion
Вероятно есть более хорошо объяснённые и написанные статьи об этом. Я не нашел, либо они были не полные для меня.
Это статья всего лишь нагромождение моего опыта и попыток подключения компилятора к IDE общего назначения, она не является руководством КАК СДЕЛАТЬ, скорее для помощи и экономии времени тех, кто имеет схожие цели.
Описываемый процесс написан чайником и предназначен для совсем чайников,может иметьимеет неточности, ошибки, использование магии и прямое вранье во имя упрощения. Если вам интересно как это действительно правильно работает и что под капотом — перепроверяйте и читайте официальные гайды.
Тут будет много «не знаю как это работает, но я так сделал и оно заработало».Пререквизиты
Суть всего этого копошения — универсализация сборки и в т.ч. независимость от IDE.
А значит, как минимум все должно собираться из командной строки. Это много где описано, но если сюда залетит еще один несчастный вроде меня и он просто не понимает кучи предстоящего неизведанного дерьма, то ниже чек-лист и мотивы того, что потребуется.
Подразумевается, что читающий будет это все понимать, до того как перейдет к следующему абзацу.- Уметь в базовые действия CLI — создать папку\файл, удалить папку\файл.
- Немножко понимать, что такое команда\программа в CLI и ее флаги.
- Немножко понимать, что существуют переменные окружения.
- Уметь собирать C\C++ hello world из под CLI через make.
- Уметь тоже самое через CMake.
- Понимать что такое toolchain.cmake файл и нафига он.
- Уметь в самые базовые действия openocd и хотя бы взглянуть как выглядят ее конфиги. Еще стоит найти принцип и пути, как оно ищет конфиги.
Сборка из под CLI
Без особых подробностей.
1. Скачать github.com/ahessling/STM32F4Template (в Readme.md репозитория есть инструкции)
2. Скачать\установить тулчейн GCC для ARM developer.arm.com/downloads/-/arm-gnu-toolchain-downloads. (не скачайте урезанную\бета версию, при установке отметьте, что бы установило переменные окружения и переменную окружения path).
3. Скачать\установить make и cmake, убедиться, что они работают из под CLI.
4. Скачать\установить openocd, убедиться, что он работает из под CLI.
5. Попробовать сконфигурировать\собрать\прошить скачанный проект.Настройка сборки в CLion
- Открыть проект как «CMake проект»
- CLion шибко умный и норовит сам взять наиболее подходящий C\C++ компилятор из системы. Я не знаю принцип его поиска, но находит он обычно компилятор для платформы системы, что ожидаемо, но нам не нужно.
- CLion не умеет сам находить\сжирать файл тулчейна. Он так же не умеет брать его из CMakeLists.txt
Нам это не нужно, мы хотим, что бы компилятор определялся в CMakeLists.txt. Но больше настроек в тулчейне мы сделать не можем, поэтому либо ставим намеренно неверные пути к компилятору, что бы максимизировать ошибку, либо прописываем верные абсолютные пути к установленному GCC ARM, конкретно к файлам *-gcc.exe \ *-g++.exe. (зачем, об этом ниже).
- Сразу ставим галочку Share. Это вынесет этот профайл в отдельный файл и позволит его использовать вместе с VCS. Иначе, это все будет храниться в неком workspace.xml, что постоянно меняется по любому чиху и по идее должен быть игнорирован.
- В поле Toolchain выбираем созданный выше.
- В CMake Options добавляем строку -DCMAKE_TOOLCHAIN_FILE=ПУТЬ-К-РЕАЛЬНОМУ-ФАЙЛУ-ТУЛЧЕЙНА-ЧТО-БЫЛ-В-РЕПОЗИТОРИИ
Траблшутинг
- Попробовать удалить папку build
- Попробовать перезапустить IDE
- При множественном долблении Reload CMake project, в случае успешной предыдущей реконфигурации, в следующих попытках конфигурации, IDE почему-то начинает использовать компилятор из «встроенного тулчейна», я не знаю почему. Это вероятно баг, я зарепортил, апдейтну если ответят.
Проявляется в виде не здоровых ворнингов: Manually-specified variables were not used by the project: CMAKE_TOOLCHAIN_FILE.
А в случае, если в «встроенном тулчейне» не указаны компиляторы, будет вообще падать с ошибкой. Именно поэтому, я в нем указал правильные пути. Просто, что бы не беспокоила мозги.Настройка отладки
- В поле Target выбираем цель CMake, чей выходной файл мы будем использовать для отладки.
- В поле Execitable binary выбираем cам выходной файл.
- В Board config file выбираем требуемый конфиг файл OpenOCD (в моем случае для STM32F4 это stm32f4discovery.cfg)
- В поле Target выбираем цель CMake, чей выходной файл мы будем использовать для отладки.
- В поле Before launch выбираем цели CMake, которые должны быть выполнены до запуска отладки, как минимум это должен быть Build.
- Закрываем все после Apply.
В открывшейся вкладке Debug, зайдя на вкладку Peripherals можно скормить *.svd файл регистров для МК и сделать доступным их просмотр.
Настройка Custom Targets
При открытии проекта, IDE так же импортирует кастомные цели CMake, там могут быть всякие полезности, вроде стирания мк, прошивки дополнительных устройств, сборка смежных проектов и т.п.
К сожалению, нормально заставить работать я их не смог. Они очень хотят executable файл, которого может попросту не быть для этой цели, а если он и есть — надо бы уметь его подтягивать с CMakeLists.txt, на не вписывать в ваши локальные конфиги IDE.Я запросил ответа у поддержки, по результатам поправлю.