Как только вы со временем устанете от Windows (в моей ситуации производительность ОС как-то ухудшилась после пары лет работы), вы можете оказаться перед дилеммой. Либо вы просто уничтожаете существующую систему, чтобы переустановить ее с нуля, либо, возможно, пришло время подобрать альтернативную систему на помощь. Недавний выпуск Ubuntu Linux кажется вполне подходящим для начала: у вас не будет проблем с просмотром Интернета, просмотром видео, прослушиванием музыки и т. д. Единственная часть головоломки, которую я сильно пропустил, — это приличная IDE для программирования на C++. Несколько лет назад я использовал Eclipse, затем попытался начать с Qt Creator и в конце концов остановился на упрощенном редакторе кода Visual Studio, который, кстати, не так уж и плох. Я также помню чувство, когда возвращался из Eclipse в Visual Studio 2005. Тогда я узнал, что такое катарсис: ты получаешь легкую и быструю IDE (да, MS Visual Studio была такой) вместо вечно занятой, но открытой -source (извините?) IDE.

Так вот вопрос: какая IDE хороша для Linux? Без цели попасть в священную войну, я просто хочу поделиться некоторыми мыслями об использовании CLion IDE, которая является коммерческим продуктом (так что да, за нее нужно платить). Возьмите то, что написано ниже, с крупинкой соли, потому что:

  1. Я новичок в CLion. Этот пост в блоге написан сразу после того, как мне удалось сжечь первую ошибку в одном из моих проектов, так что IDE была продуктивно использована. В то же время, чтобы полностью оценить IDE, вы должны использовать ее месяцами.
  2. Я использовал некоторые другие IDE, такие как Eclipse (10 лет назад или около того). Я не фанат Eclipse и, исходя из своего старого опыта, стараюсь избегать этой IDE, насколько это возможно. Возможно, сейчас эта IDE намного лучше, чем была, когда я немного программировал на Java. Но воспоминания полны боли.

Начало работы в Windows

CLion можно легко скачать с сайта JetBrains. Я начал тестировать его на Windows, которая до сих пор является моей центральной рабочей системой для всех проектов, которые я делаю (в основном из-за Visual Studio). Раньше я не знал о JetBrains и их продуктах. Наверное, потому что я не в курсе последних технологий. На самом деле, вам не нужно так много, чтобы чувствовать себя комфортно в геометрическом моделировании, которое является моей областью. Окружая свой любимый набор проверенных библиотек (типа Qt, OpenCascade, VTK и т. д.) достаточно хорошей IDE, вы не будете чувствовать, что остальной мир движется куда-то вперед, пока вы застряли с инструментами вашего дедушки. Либо наша область настолько консервативна, либо мне лень идти в ногу со всеми видами захватывающих технологий и языков, появляющихся каждый год или около того.

После нескольких часов гугления я начал ценить послание JetBrains рынку. Они делают инструменты для разработчиков программного обеспечения, и, поскольку они сами являются разработчиками, они едят свою собственную собачью еду (JetBrains, похоже, нравится это высказывание), чтобы лучше чувствовать свои продукты и улучшать их на основе собственного опыта. Это действительно блестящая практика. Такого же стиля работы мы придерживаемся и в нашем продукте CAD Processor. Даже превосходная команда QA не даст того уровня уверенности и удовлетворения, которые вы получаете от собственного опыта использования вашего инструмента для решения собственных задач. JetBrains также известна своим языком программирования Kotlin. Компания, достаточно амбициозная, чтобы начать изобретать новый язык программирования, безусловно, заслуживает внимания.

CLion — это IDE. Это ни в коем случае не компилятор или система конфигурации. Набор инструментов для создания ваших проектов можно настроить сразу после первого запуска IDE. Я выбрал существующий набор инструментов MSVC (Visual Studio 2017 Professional в моем случае) в качестве «среды», чтобы позволить IDE самостоятельно находить все остальное. Помимо автоматического поиска компилятора и отладчика C/C++, CLion также обнаруживает бинарные файлы CMake (у него есть пакет CMake внутри). Поскольку я использую CMake всякий раз, когда могу, это стало еще одним приятным сюрпризом: до сих пор процесс настройки был довольно простым. Не знаю, правда, насколько это было бы просто в случае, когда вы не мигрируете с уже развернутой среды разработки (со всеми этими Visual Studios и CMakes вон там), а начинаете с чистого листа.

Графический интерфейс CLion выглядит довольно привлекательно. Он изначально поддерживает темную и белую темы, в то время как моя любимая темная тема выглядит достаточно отполированной (эта тема называется Darcula в CLion). Хотя я бы предпочел немного больше контраста в темной теме, она все же намного лучше, чем то, что я давным-давно настраивал вручную в Visual Studio 2010. Неплохо. Документация, доступная на сайте, тоже выглядит неплохо.

Процесс настройки в CLion тесно связан с CMake. Чтобы переключаться между типами сборки (т. е. Release и Debug), нужно перейти к реквизитам CMake на соответствующей панели графического интерфейса CLion. При перенастройке CMake среда IDE создаст каталог сборки (по умолчанию это каталог прямо в исходной папке) с именем, отражающим тип сборки (с суффиксами «-debug» и «-release»).

Не забудьте правильно выбрать целевую архитектуру (x86 или x64). Значение по умолчанию — x86, и это было неправильным параметром в моей среде. Такая неправильная конфигурация останется незамеченной до тех пор, пока сборка не будет завершена (неудачно).

Вместо того, чтобы открывать CMake GUI, который был для меня вполне привычной утилитой, в CLion я настраивал все переменные CMake прямо в файле CMakeCache.txt. Не уверен, что это именно тот способ настройки, который был разработан, но, учитывая, что выходные данные CMake всегда под рукой, такой новый метод не кажется непрактичным. Я пропустил какой-то более сложный способ конфигурации?

Запуск из IDE

Раньше в Visual Studio мы устанавливали свойство Environment для отладки сразу из IDE.

Visual Studio позволяет указать переменную среды PATH, чтобы гарантировать, что все библиотеки времени выполнения будут выбраны при запуске исполняемого файла. Отсутствие окружения было первой болезненной вещью, с которой я столкнулся в CLion. Даже если ваш проект успешно собран, он не запустится, если у вас нет всех зависимых библиотек (so для Linux и dll для Windows) в пути выполнения. Проведя пару часов в Интернете, я обнаружил, что в процессе миграции не хватает лучших практик. На YouTube есть много видеороликов, рассказывающих об инструментах рефакторинга и гладкой интеграции CMake, где CLion, кажется, превосходит другие. Но слишком мало (если вообще есть) туториалов о том, как настроить вещи для существующего (здесь можно поставить устаревшее) промышленного проекта. Такие проекты настолько отличаются от приложений Hello World, что мне интересно, насколько CLion масштабируем. Будет ли это хорошо работать для проекта с миллионами строк кода? Будут ли эти инструменты рефакторинга настолько эффективны для такой обширной базы кода? В конце концов, имеет ли значение с точки зрения эффективности то, что CLion — это приложение на основе Java? Одна из ссылок для ознакомления — Советы по настройке производительности CLion.

После нескольких часов отладки я обнаружил, что CLion (по сути, JVM) не освобождает память даже после остановки приложения. Чтобы освободить выделенную оперативную память, кажется, необходимо убить процесс «java», хотя такое убийство, безусловно, закроет IDE. Кто-нибудь знает об этом? Или я делаю что-то глупое со своей стороны?

Возвращаясь к проблеме среды, это можно исправить, зайдя в панель «Редактировать конфигурации…» и добавив туда переменные вручную. Не так уж сильно отличается от привычного способа сделать это в Visual Studio.

При таком подходе остаются два вопроса:

  1. Как настроить разные переменные времени выполнения для отладки и выпуска? Вы никогда не должны смешивать оба.
  2. Как избежать ручной настройки окружения? То есть, когда проект клонируется из репозитория в первый раз, вы вряд ли захотите потратить пару незабываемых часов на то, чтобы понять, как запустить его из IDE.

Настройки IDE для проекта доступны в файле .idea/workspace.xml. Он включает в себя переменные среды, которые вы установили для среды выполнения. В соответствии с тем, как JetBrains рекомендует настроить свой .gitignore, файл workspace.xml зависит от машины, поэтому им не следует делиться с командой. С другой стороны, вероятно, можно обобщить эти XML-файлы, чтобы избежать полных путей. Таким образом, мы должны иметь возможность совместно использовать среду выполнения, что избавляет от необходимости локальной настройки.

Тестирование после сборки?

В Analysis Situs мы используем событие после сборки для запуска модульного тестирования сразу после завершения процесса сборки. В CLion такой прием больше не работает. Логика запуска юнит-тестов в CMake была настроена следующим образом:

# Post build event: run tests.
add_custom_command(
        TARGET asiTest
        POST_BUILD
        COMMAND ${CMAKE_COMMAND} -E echo "Running unit tests..."
        COMMAND IF 1==$<CONFIG:Release> ( call ${asiTest_BINARY_DIR}/setenv_rel.bat && $<TARGET_FILE:asiTest> )
        COMMAND IF 1==$<CONFIG:RelWithDebInfo> ( call ${asiTest_BINARY_DIR}/setenv_rel.bat && $<TARGET_FILE:asiTest> )
        COMMAND IF 1==$<CONFIG:Debug> ( call ${asiTest_BINARY_DIR}/setenv_deb.bat && $<TARGET_FILE:asiTest> )
    )

Оказывается, такой трюк не только специфичен для ОС (его исключили из конфигурации Linux), но и специфичен для IDE. Существуют интеграции CLion с некоторыми приличными средами модульного тестирования, такими как Google Test, но я бы не хотел проводить рефакторинг системы модульного тестирования из-за IDE. Самый простой способ разблокировки — временно отключить модульные тесты. Для этого в CMake можно проверить, определена ли переменная CLION_IDE, и если да, то не включать в проект соответствующие таргеты.

if (NOT $ENV{CLION_IDE})
  set_property(TARGET MyUnitTestsExe PROPERTY FOLDER Executables)
endif()

Начало работы в Linux

Установка в Linux так же проста, как и в Windows. После загрузки архива CLion с веб-сайта JetBrains просто распакуйте его в системный каталог:

sudo tar xzf CLion-2020.1.tar.gz -C /opt

Процесс импорта существующего проекта CMake и его компиляции был довольно простым. Как и в случае с Windows, мне пришлось вручную изменить файл CMakeCache.txt, чтобы настроить все переменные конфигурации. Потратив на это около десяти минут, я укрепился во мнении, что было бы намного лучше иметь упрощенный пользовательский интерфейс для CMake. Есть ли он? Если да, то как его включить? Но, хорошо, даже изменяя кеш таким образом, вы не столкнетесь с проблемами блокировки.

Как только проект скомпилирован, пришло время его запустить и отладить. Поскольку лично у меня есть трудности с отладкой в ​​Linux (да, я ненавижу отладку в консоли), простая возможность визуального контроля во время выполнения, заход и повтор, установка точек останова и т. д. сама по себе является огромным делом для меня. На самом деле не имеет значения, какая IDE превращает этот жуткий GDB во что-то съедобное. Важно то, насколько прост процесс настройки. Так что это был момент истины. Как и ожидалось, я не мог просто запустить скомпилированное приложение, так как библиотеки зависимостей не находились ни в рабочей директории, ни в системном пути (должны были быть Qt, VTK, OpenCascade и многие другие). Поэтому мне пришлось установить переменную LD_LIBRARY_PATH по-своему. Вот тут-то я и сделал первую ошибку: нужно установить среду для исполняемого файла, а не в глобальных настройках. Прежде чем обнаружить это (должен признать, это вполне логично, так что это было полностью мое ошибка), я попытался проверить ситуацию, установив и напечатав LD_LIBRARY_PATH в терминале. Хотя в документации написано, что есть Терминальное окно, я какое-то время не мог его включить. Случайно обнаружил, что нужно ставить еле уловимую галочку у соответствующего (и предустановленного) плагина в панели настроек. Вот как это выглядит (обратите внимание на маленькую галочку справа):

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

Вывод

Чтобы объективно оценить ту или иную IDE, нужно некоторое время с ней работать. В идеале проекты, которые вы делаете, не должны быть похожи на самостоятельные студенческие упражнения. В противном случае вы не поймете, насколько хороша IDE применительно к реальному промышленному программированию. Некоторые из вещей, которые мне понравились в продукте CLion, перечислены ниже:

  1. Его легко установить и настроить. Наверное, это потому, что почти все мои проекты уже были в CMake. Это идеально подходило для меня, но я не уверен, что мой опыт масштабируется.
  2. Графический интерфейс дружественный. Некоторые мелкие настройки, которые я не мог найти, читая онлайн-документацию или просматривая обзорные видеоролики, я в итоге разобрался сам интуитивно.
  3. IDE выглядит мощно. Он предоставляет множество инструментов для работы с семантикой вашего кода, включая всевозможные средства поиска, утилиты расширения макросов, рецепты рефакторинга и многое другое. Не забывайте про статические анализаторы кода и интеграции с такими популярными инструментами, как Valgrind. На данный момент я не оценил все варианты, так как такие эксперименты занимают много времени.
  4. Ребята, разрабатывающие CLion, опубликовали множество вводных видеороликов, в том числе содержательные доклады на конференциях. Следите за ними, чтобы лучше изучить IDE: это стоит того времени, которое вы на это потратите.

Однако остаются некоторые вопросы. Как у любого, кто попался на первоклассном инструментальном средстве Visual Studio, у меня возникли трудности с настройкой привычного способа работы в новой IDE. Многие вопросы, подобные вопросу с модульными тестами, остаются для меня нерешенными. Кроме того, хотя в целом выглядит неплохо, пользовательский интерфейс IDE субъективно хуже, чем в продуктах Microsoft. Мне не понравилось очень контрастное дерево проектов в схеме Darcula: оно сильно отвлекает от редактора из-за слишком яркого цвета шрифта. Расположение элементов управления графическим интерфейсом также кажется мне немного запутанным (вероятно, снова из-за шрифтов). Некоторые панели (например, Терминал) трудно активировать. Горячие клавиши отличаются от знакомых комбинаций Visual Studio, и мне до сих пор трудно переключаться между ними.

Мне также не удалось найти панель конфигурации CMake, чтобы избежать редактирования файла CMakeCache.txt вручную (это может быть хорошо для инструментов с открытым исходным кодом, но не для IDE коммерческого уровня). Вопрос о настройке CMake я задал на недавнем вебинаре от JetBrains, посвященном CLion. Вот мой вопрос:

«При настройке моего проекта я редактирую файл CMakeCache.txt вручную, чтобы установить переменные CMake. У меня есть ощущение, что это не тот способ конфигурации CMake, который был разработан в CLion. Я пропустил какой-то более простой способ сделать это, например, специальный графический интерфейс для ввода переменных CMake? Я бы ожидал чего-то вроде старого знакомого cmake-gui».

И ответ был:

Вы все еще можете сделать это вручную в CMakeCache. Но есть и такие настройки: «перейти по ссылке.

Таким образом, мы можем определить некоторые переменные, но в любом случае это не похоже на использование cmake-gui.

Без сомнения, проведя несколько месяцев в среде IDE, человек привыкает ко всевозможным нестыковкам и находит какие-то хитрости, чтобы оставаться продуктивным. Несмотря на то, что CLion основан на старой доброй IntelliJ IDEA, есть надежда, что команда разработчиков CLion не слишком ограничена рамками базового фреймворка. Однако они, вероятно, ограничены Java больше, чем собственным кодом. Я был очень разочарован, увидев, сколько памяти потребляет JVM после нескольких попыток отладки методом проб и ошибок. Вы должны следить за ресурсами оперативной памяти и время от времени убивать Java. Это очень плохо. Если все пойдет так, то следующая IDE, которую я выберу для C++ (на случай, если CLion не взлетит), не будет основана на Java. Кто-нибудь знает хорошие кроссплатформенные IDE с поддержкой CMake и без Java внутри?

Вопрос о неиспользованной памяти я задавал на недавнем вебинаре от JetBrains, посвященном CLion. Вот мой вопрос:

«Иногда после отладки я вижу, что оперативная память не освобождается, даже если отлаживаемая программа закрыта. Я использую, чтобы убить процесс CLion и перезапустить его, чтобы решить эту проблему. Кто-нибудь сталкивается с подобными проблемами при отладке? CLion 2020.1.1, Linux Ubuntu 18_04».

И ответ был:

Может быть, вы можете сообщить, с некоторыми дополнительными журналами (как описано здесь).

Так что, видимо, не все сталкиваются с этим каждый божий день. Это считается ошибкой, и это звучит многообещающе.

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