Как настроить 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, если вы выберете эту опцию.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Отображение кириллицы в CLion
CLion по дефолту использует UTF-8 для хранения файлов с исходным кодом. Строка «Привет, Мир!» будет представлять собой последовательность (в файле с исходником):
D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82 2C 20 D0 9C D0 B8 D1 80 21
Как видите, на 12 символов исходной строки, получили 21 байт (т.к. кириллические символы занимают больше одного байта).
Компилятор GCC по умолчанию читает исходники в кодировке UTF8 , если не указать другую через ключ -finput-charset . Таким образом эта последовательность байтов в неизменном виде сохранится в исполняемый файл.
При запуске программы на исполнение, CLion использует стандартный cmd.exe , который по умолчанию скорей всего у вас работает в кодировке CP866 . В которой наша последовательность байтов будет отображена как:
╨Я╤А╨╕╨▓╨╡╤В, ╨Ь╨╕╤А!
(что вы и видите в терминале CLion)
Что делать?
Вариант 1
Сменить кодировку файла на IBM866 (то же, что и CP866 ) (настройки — File Encodings) (сам файл перекодировать, если в нем уже был текст на русском). Теперь кириллица будет сохраняться в файле с исходным текстом в кодировке CP866 (один байт на символ), в том же виде попадать в исполняемый файл и нормально отображаться в консоли CLion. Разумеется, использовать CP866 в 19-м году, без особых на то оснований, некультурно. Кроме того придется ограничить себя символами из CP866 .
Вариант 2
Вставить в начало свой программы:
system("chcp 65001");
или (потребует #include ):
SetConsoleOutputCP(CP_UTF8);
Консоль переключится в UTF-8 , все будет отображаться как надо. Но только при использовании низкоуровневых операций вывода типа puts(«Привет, Мир!»); . Если выводить через std::cout , то возможен вывод типа ��ривет, Мир! . Это связано с тем, что функция Windows API для вывода в консоль ожидает увидеть в каждом вызове законченную строку. И если оператор basic_ostream::operator
Предостережение
При использовании UTF-8 в своей программе, например при хранении в std::string , следует помнить, что операции над строками могут дать не очевидные результаты (т.к. один символ теперь может занимать от 1 до 4 байтов).
Кроме вывода, аналогичные проблемы ожидают и при вводе из std::cin . Таким образом, единственным прозрачным решением для Windows (даже десятки), пока остается использование латиницы.
Как изменить тему в CLion
Clion — это популярная интегрированная среда разработки (IDE), используемая программистами для разработки программ на языке C++. Одним из важных аспектов работы в Clion является выбор подходящей темы оформления. Внешний вид IDE может значительно повлиять на комфорт и продуктивность разработки, поэтому важно знать, как изменить тему в Clion.
Смена темы в Clion осуществляется через настройки IDE. Для начала, откройте Clion и выберите пункт меню «File» (Файл) в верхней панели. Затем выберите «Settings» (Настройки). Это откроет панель настроек Clion.
В панели настроек найдите раздел «Appearance & Behavior» (Внешний вид и поведение) и выберите «Appearance» (Внешний вид). Здесь вы увидите список доступных тем оформления. Clion предлагает несколько встроенных тем, таких как «Darcula» и «IntelliJ», а также возможность установки дополнительных тем, загруженных из Интернета.
Чтобы сменить тему, просто выберите нужную тему из списка. Мгновенно после выбора темы ваше рабочее пространство в Clion будет обновлено с учетом выбранной темы. Если вам не нравится новая тема, в любое время вы можете вернуться к предыдущей, выбрав ее в списке тем.
О Clion
Clion — это интегрированная среда разработки, специально созданная для программистов на языке C и C++. Она предлагает широкий набор инструментов и функций, которые облегчают процесс разработки и увеличивают продуктивность работы.
Среди основных возможностей Clion можно выделить:
- Интеллектуальное автодополнение кода: Clion предлагает автодополнение кода на основе контекста и предыдущего кода, что ускоряет написание кода и уменьшает количество ошибок.
- Отладка кода: Clion предоставляет удобный отладчик, позволяющий искать и исправлять ошибки в коде.
- Инструменты для рефакторинга кода: Clion позволяет автоматически переименовывать переменные, извлекать методы, удалять неиспользуемый код и многое другое.
- Поддержка системы контроля версий: Clion интегрируется с популярными системами контроля версий, такими как Git и Subversion, что позволяет легко отслеживать изменения в коде и сотрудничать с другими разработчиками.
- Работа с большими проектами: Clion позволяет удобно работать с большими проектами, предоставляя инструменты для навигации по коду, поиска классов и функций, а также быстрого перехода к определению или использованию.
- Интеграция с популярными фреймворками и инструментами: Clion поддерживает интеграцию с различными фреймворками и инструментами, такими как CMake, Boost и Google Test, что упрощает работу с ними и повышает производительность.
Системные требования для установки Clion
При использовании Clion можно значительно увеличить производительность и удобство разработки, а также ускорить процесс отладки и рефакторинга кода.
Шаг 1: Открытие настроек Clion
Для изменения темы в Clion необходимо открыть окно настроек IDE. Чтобы это сделать, следуйте следующим шагам:
- Откройте Clion.
- Перейдите в меню «File» (Файл) в верхней панели навигации.
- Выберите пункт «Settings» (Настройки) в выпадающем меню. Откроется окно настроек.
Можно также использовать сочетание клавиш Ctrl + Alt + S, чтобы быстро открыть окно настроек.
После выполнения этих шагов вы увидите окно настроек Clion, где можно изменять различные параметры среды разработки.
Шаг 2: Поиск доступных тем
Clion предлагает несколько вариантов тем оформления, чтобы вы могли выбрать то, которое вам нравится больше всего. Чтобы найти доступные темы, выполните следующие действия:
- Откройте окно настроек Clion, выбрав вкладку «File» в верхнем меню и затем выбрав «Settings» (или используйте сочетание клавиш Ctrl+Alt+S на Windows/Linux или Cmd+, на macOS).
- В окне настроек выберите вкладку «Appearance & Behavior» в левой части окна.
- В разделе «Theme» вы увидите список доступных тем оформления.
- Используйте поле поиска или пролистывайте список тем, чтобы найти то, что вам нравится.
- Выберите тему, которую хотите установить, щелкнув по ней один раз.
Вы также можете установить собственные темы оформления, если у вас есть файлы с расширением «.jar» или «.zip». Для этого нажмите кнопку «Install Theme…», выберите файл темы и нажмите «Apply».
После выбора темы оформления, вы увидите, как она применяется к окнам и элементам интерфейса Clion. Если вы не удовлетворены выбранной темой, вы всегда можете вернуться в окно настроек и выбрать другую, чтобы изменить внешний вид своей среды разработки.
Шаг 3: Смена темы
После установки и запуска CLion, вы можете легко изменить тему, чтобы соответствовать вашим предпочтениям и настроить внешний вид среды разработки. Вот как это можно сделать:
- Откройте CLion и перейдите в меню «File» (Файл).
- Выберите пункт меню «Settings» (Настройки), чтобы открыть окно настроек.
- В окне настроек найдите и выберите раздел «Appearance & Behavior» (Внешний вид и поведение).
- В подразделе «Appearance» (Внешний вид) вы увидите опцию «Theme» (Тема). Щелкните на выпадающем списке, чтобы открыть доступные темы.
- Выберите из списка тему, которая вам нравится и предпочитаете использовать при работе.
- После выбора темы, она немедленно применится к среде разработки CLion.
Теперь вы можете наслаждаться новой темой в CLion, которая лучше соответствует вашим визуальным предпочтениям и помогает вам с фокусировкой на разработке вашего кода.
Шаг 4: Персонализация темы
Clion предлагает несколько вариантов тем, которые вы можете выбрать для своей рабочей среды разработки. Однако, если вы хотите достичь большей индивидуальности в своей работе, Clion также предлагает возможность персонализации темы.
Чтобы изменить тему в Clion:
- Откройте настройки программы, выбрав пункт «File» (Файл) в верхнем меню и выбрав «Settings» (Настройки) в выпадающем меню.
- В окне настроек выберите пункт «Appearance & Behavior» (Внешний вид и поведение) в левой панели.
- Выберите вкладку «Appearance» (Внешний вид).
- В разделе «Theme» (Тема) вы увидите список доступных тем. Чтобы выбрать тему, щелкните на нее. Вы также можете установить пользовательскую тему, щелкнув на кнопку «…» (Троеточие) рядом с выпадающим списком тем.
- Когда вы выбрали тему, нажмите кнопку «Apply» (Применить), а затем «OK» (ОК), чтобы сохранить изменения и закрыть окно настроек.
После выполнения этих шагов, тема вашей рабочей среды Clion будет успешно изменена. Вы можете экспериментировать с различными темами, чтобы найти наиболее подходящую для себя.
Вопрос-ответ
Как сменить тему в Clion?
Для смены темы в Clion перейдите в меню «File» (Файл), выберите «Settings» (Настройки), затем «Editor» (Редактор) и «Color Scheme» (Цветовая схема). В открывшемся окне вы можете выбрать одну из предустановленных тем или установить свою собственную.
Какое преимущество в смене темы в Clion?
Смена темы в Clion позволяет настроить внешний вид и цвета редактора, что может улучшить комфортность работы. Выбор темы также может помочь вам снизить усталость глаз при долгом использовании IDE.
Можно ли установить собственную тему в Clion?
Да, в Clion можно установить свою собственную тему. Для этого перейдите в меню «File» (Файл), выберите «Settings» (Настройки), затем «Editor» (Редактор) и «Color Scheme» (Цветовая схема). В окне выбора темы нажмите кнопку «Manage» (Управление) и выберите «Import Scheme» (Импорт схемы). Затем выберите файл с вашей собственной темой и нажмите «OK» (ОК).
Как изменить только цвета в теме в Clion?
Для изменения только цветов в теме в Clion перейдите в меню «File» (Файл), выберите «Settings» (Настройки), затем «Editor» (Редактор) и «Color Scheme» (Цветовая схема). В настройках цветовой схемы вы можете изменить отдельные цвета для различных элементов редактора, таких как фон, шрифт, комментарии и т. д.
Как работать с 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 */) = 0
foo.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.c
main.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), но об этом — в следующей статье.