Кстати, если у вас уже есть лицензия CLion (купленная до 2 ноября или после запуска новой лицензионной модели), этот апдейт Вы получаете абсолютно бесплатно. Итак, что же внутри?
Google Test
Одно из главных нововведений этого релиза — поддержка Google Test и возможность запускать тесты прямо из IDE. Для этого в CLion реализованы специальные конфигурации, которые создаются автоматически при запуске теста, файла с тестами, тестового класса или вручную в настройках. В настройках конфигурации указывается, какие тесты запускать, какой при этом таргет вызвать и пр.:
Непосредственно запустить тест можно через контекстное меню или по сочетанию клавиш (
Ctrl+Shift+F10 на Windows/Linux, Ctrl-Shift-R на OS X). Результат запуска будет отображаться в специальном окне:
Интерфейс наверняка знаком тем, кто использовал/использует другие продукты на основе нашей платформы IntelliJ. Из этого окна можно:
- перезапустить все тесты или только упавшие;
- отсортировать тесты по имени или по длительности прохождения;
- посмотреть/перейти на код конкретного теста;
- посмотреть вывод каждого конкретного теста и сообщения об ошибках;
- перенести результаты текущего запуска тестов в файл;
- посмотреть предыдущие запуски тестов по истории, которая сохраняется автоматически.
Для облегчения же непосредственно написания тестов мы добавили кодогенерацию:
Меню появляется по нажатию на
Alt+Insert на Windows/Linux, Cmd-N на OS X, и предлагает сгенерировать один тест, тестовый класс (fixture) и стандартную пару методов SetUp/TearDown. При этом генерация непосредственно тестового метода хитрая — сначала всегда создается макрос TEST(), а потом, в зависимости от контекста, он автоматически заменяется на более подходящий. Например, при указании имени существующей fixture, макрос автоматически заменяется на TEST_F():
Более детально прочитать и посмотреть про Google Test в CLion 1.2 можно в нашем англоязычном блоге и в соответствующем видео на канале YouTube.
Улучшения по поддержке C++
В данный релиз вошло более 50 исправлений, связанных с языком C++. Например, поддержка макроса __LINE__, необходимого для разработки под Unreal Engine 4 и не только. (Кстати, о получении CMake проекта для работы с UE4 в CLion читайте статью на английском от нашего коллеги).
Наши IDE известны тем, что умеют выводить типы, а с появлением C++11 это стало актуально и для C++. Дело в том, что определить тип у переменной, объявленной как auto, не всегда просто, нужно долго и внимательно изучать, какой же вызов присваивает значение в переменную. Здесь приходит на помощь IDE — всплывающее окно Quick Documentation покажет нужный тип. В новой версии CLion 1.2 поправлено несколько проблем с выводом таких типов:
Продолжая работу над шаблонами, мы реализовали поиск использований и рефакторинг переименования для шаблонных параметров. А на случай, если параметр никак не используется, в IDE добавили возможность умного удаления (quick-fix) параметра из определения и использований шаблона:
CMake
Для облегчения написания файлов CMake в CLion 1.2 появились две возможности:
- готовые шаблоны (Live Templates) и
- автодополнение переменных.
Мы добавили несколько готовых шаблонов: foreach, function, if, macro, while, incboost (который помогает подключить библиотеки Boost к проекту). Также вы можете создавать свои и использовать их в файлах CMake. Как и для других аналогичных шаблонов, для аббревиатур шаблонов есть автодополнение, а раскрывается шаблон по нажатию клавиши
Tab (или другой сконфигурированной в настройках):
В предыдущих версиях уже присутствовало автодополнение команд CMake, а теперь мы реализовали автодополение переменных (пока только тех, у которых имена статические).
Также появилась опция в настройках форматирования, позволяющая использовать всегда только заглавные или всегда только строчные буквы для команд CMake (допустИм и вариант смешенного стиля).
Отладчик
Главные изменения во встроенном отладчике — это работа над производительностью. Мы внесли много изменений, которые заметно улучшили ситуацию (но нам еще есть, куда стремиться). Таких, например, как “ленивое” создание переменных для GDB.
Также было сделано несколько изменений в рендеринге переменных типа references и массивов символов Юникод:
Платформенные изменения
Как и другие IDE на платформе IntelliJ, CLion получил ряд общих улучшений:
- Появился quick-fix, который позволяет поменять настроки форматирования, актуальные только для выделенного куска кода. Это работает во всех языках, поддерживаемых в CLion (C++, C, CMake, языки для WEB разработки).
- При поиске по пути (Find in Path) в соответствующем диалоге добавлена вкладка предпросмотра, которая отображает первые 100 результатов поиска и существенно облегчает задачу.
- При выполнении поиска и замены теперь можно использовать регулярные выражения.
- Множество улучшений для разных систем контроля версий (добавился Perforce Shelve, работа с патчами Mercurial Queues, Git операции для бранча собраны теперь в одном меню).
- Внешний вид также претерпел изменения, особенно это заметно будет пользователям HiDPI Linux/Windows, и пользователям дефолтной (“белой”) схемы на OS X. И, кстати, версия для OS X теперь по умолчанию собрана с кастомизированной JDK с исправлениями от JetBrains, но при этом в самой IDE можно выбрать любую JDK, установленную в системе.
В завершение небольшой деморолик (на английском):
Следите за постами в нашем англоязычном блоге и читайте подробнее про возможности новой версии CLion 1.2 на сайте. Как обычно, есть 30-дневная бесплатная пробная версия, а в разделе цен можно узнать о стоимости по новой модели и варианты лицензирования. Мы рады ответить на любые ваши вопросы в комментариях.
Программируйте с удовольствием!
Ваша команда JetBrains CLion
Комментарии (40)
gurinderu
05.11.2015 14:52За google test спасибо огромное. Можно еще запилить поддержку https://github.com/google/benchmark?
anastasiak2512
05.11.2015 14:55Добавьте, пожалуйста, в трекер запрос. Оценим, что и когда можем сделать.
Randl
05.11.2015 15:06+2Хотелось бы поддержку Valgrind, gprof и импорт/поддержку других систем сборки.
И баг с буфером обмена очень противный. Но вы конечно, медленно но верно движетесь к идеалу. Спасибо вам за это.anastasiak2512
05.11.2015 15:32Спасибо за комментарий и за приятный фидбек.
Соответствующие запросы есть в трекере, там можно за ними следить:
А что за баг с буфером обмена, напомните? Может, есть ссылка на трекер?Randl
05.11.2015 15:51+3Запрос на gprof я и запостил ;)
Valgrind, как и Makefile(а заодно Qt, Visual Studio, Autotools) это один из самых популярных фич-реквестов уже давно. Но и объем работы для них, очевидно, немаленький, поэтому продолжаем ждать.
Баг с буфером обмена.anastasiak2512
05.11.2015 16:47Понятно. Спасибо за ссылку и напоминание. Посмотрим, что можем сделать.
Randl
06.11.2015 14:37Можете заодно пояснить мотивацию политики «всё что связано с VS (toolchain, projects) — только ReSharper и никак не Clion»? Кроме желания продавать два продукта естественно.
Я получил как-то ответ, что Clion нацелен на кросс-платформенную разработку, и VS тут не в тему. Но
а). Не кросс-платформенные инструменты (Valgrind, LLDB) не получили такую же реакцию
б). VS не исключает кросс-платформенность. Тот же Cmake генерирует VS проекты, а V8, например, под Win больше ничем не собрать.anastasiak2512
06.11.2015 14:39В условиях наличия ReSharper C++ пока не понятно, зачем бы сейчас тратить ценные ресурсы команды на VS toolchain в CLion. То есть не то, чтобы мы об этом не думали вообще. Просто пока это задача за рамками проекта. Есть много куда как более важных.
Randl
06.11.2015 15:40За рамками проекта или не в приоритете?
Зачем — как раз по-моему вполне очевидно. Хочется одну IDE для все проектах на плюсах. С той же целью у вас и просят поддерживать кучу вещей: Makefile, Qt, Arduino, cross-compilation, Autotools, VS toolchain, SCons, Gradle, ninja, CUDA, intel compiler, Bazel, GLSL ES — это только с первой страницы, то есть с более-менее большим количеством голосов.
Ну то есть понятно, что вы пытаетесь покрыть максимальную аудиторию, и к тому же выпускать продукты с пересекающейся функциональностью не очень выгодно. Но очень хочется оставить на компьютере CLion единственной IDE. Думаю и вам приятно будет.anastasiak2512
06.11.2015 15:55Мы это понимаем. За рамками — на данный момент. Но то есть совсем не в приоритете пока что) Как Вы верно заметили на первой странице и так много всего. Чуть позже, возможно, мы вернемся к этому вопросу и подумаем, стоит ли нам это делать или есть еще какие-то варианты (вообще они есть, но о них пока рано). Но чтобы никого зря не обнадеживать, пока отвечаем, что за рамками проекта.
monah_tuk
06.11.2015 07:32CMake
Как обстоят дела с поддержкой Generic projects? Есть проекты которые перевести на CMake сииииильно сложно. В том же QtC есть поддержка т.н. Generic Project Manger, когда ты указываешь директорию, сканируются исходники, просто составляется список, этот список используется для парсера, команду билда можно указать вручную. Ну плюс всякие настроки, типа определения дефайнов, путей поиска заголовочных файлов и т.п., ручное указание бинарника для запуска.
Git операции для бранча собраны теперь в одном меню
с недавных пор в QtC есть отличная фича: при наличии озменений на бранче, при переключении на другой бранч есть возможность сделать Stash изменениям (при этом указывается определённая метка), а при возврате на этот бранч сразу сделать Stash pop этим изменениям. Крайне удобно при работе над несколькими проблемами: нет нужды делать комит для какого-нибудь дебажного изменения. Есть ли что-то подобное в CLion?monah_tuk
06.11.2015 08:58И да, что-то не увидел возможности удалённой отладки (актуально для всяких связок типа gdb+openocd). И отладчик можно только один для всех проектов использовать?
Хотя проект для FX3 с моими правилами (https://github.com/h4tr3d/fx3-cmake) переварил нормально :)anastasiak2512
06.11.2015 11:44Удаленной отладки пока нет. Думаем про нее в рамках вот этой задачи.
Думаю, что сначала появится attach to local process, потом вероятно to remote, а потом уже и до удаленной отладки в широком смысле доберемся. Пока временных интервалов не могу предложить.
Настройки toolchain (в частности отладчика) пока что per IDE, а не per project. То есть можно только в целом сменить выбранный отладчик. Если кажется, что нужно это делать per project, добавьте в трекер, пожалуйста. Мы подумаем.monah_tuk
06.11.2015 15:36Настройки toolchain (в частности отладчика) пока что per IDE, а не per project. То есть можно только в целом сменить выбранный отладчик. Если кажется, что нужно это делать per project, добавьте в трекер, пожалуйста. Мы подумаем.
Это действительно нужно. К примеру, у меня есть tollchain для ARM, для десктопа (два разных компилятора), тулчейн для ARM — Cypress FX3. Зарегестрируюсь, попробую создать. Понятно, что cmake один используется (кстати почему-то эмбедщики любят всякую экзотику в качестве систем сборки, на своём проекте на свой страх и риск пропихнул CMake — пока только профит получаю, хотя с правилами помучаться пришлось), но вот GDB тут нужен разный. Как минимум три: на свои ARM'ы (они разные: Cortex-M3 и ARM926E-JS) и на десктоп. Вообще, изначально было неплохо идея тулчейна и разных компонент в том же QtC реализована была, сейчас правда несколько наворотили и для двух разный remote отладчиков приходится создавать два разных тулчейна, что не есть удобно.
ЗЫ за отсылки к QtC прошу прощение — основной инструмент. При всех своих косяках, отыгрывается скоростью, удобством в некоторых мелочах (без их Locator'а в других IDE сильно непривычно, и вроде есть схожие инструменты, а всё не то) и возможностью залезть в исходники и что-то оперативно исправить. Ваша IDE интересна возможностями рефакторинга.anastasiak2512
06.11.2015 15:39Спасибо за подробное пояснение. Будем благодарны, если опишите хотя бы коротенько это в реквесте в трекере.
anastasiak2512
06.11.2015 11:41Сейчас CLion поддерживает только CMake, и планируются другие проектные модели в будущем (типа Makefiles, итд). Generic projects — это фактический означает, что будет свой кастомный формат проекта и UI для его настроек. Мы периодически задумываемся о таком варианте, но кажется, что лучше поддерживать известные форматы. Довольно много настроек придется в противном случае протаскивать в UI, к тому же надо будет изобретать свой велосипед с форматом проекта для IDE. Как-то пока это не выглядит как удобное решение.
Да и можно все тоже сделать заимпортировав проект в CMake прямо в CLion, доуказав стандарт языка, стандартную библиотеку, пр. в файле CMake, сгенерированным IDE, а список сорс-файлов и заголовочные файлы задаются в интерфейсе при импорте и добавляются в файл CMake проекта автоматически при импорте. Недостаток разве что в том, что после этого шага все изменения в CMake уже придется вносить самому.
Да, про изменения в бранче, ровно такой функциональности действительно не хватает (можно повоутить тикет, если кажется, что это надо). Можно либо руками делать stash, либо автоматический smart checkout использовать, но он накатывает изменения и на второй бранч, который чекаутим.
oYASo
06.11.2015 11:59В CMake есть такая штука, как ExternalProject. С помощью нее можно указать, как собирать и линковаться со сторонним проектом (указывается имя стороннего таргета, которое потом можно юзать в target_link_libraries).
anastasiak2512
06.11.2015 12:12Да, есть. Правда пока что в CLion есть проблемы по работе с этой конкретной командой. Планируем заняться в ближайшее время. Посмотрим, что можем сделать.
oYASo
06.11.2015 11:56Хорошие новости!
Есть такие вопросы:
1) Поддержка mingw64 уже есть?
2) Научился ли дебаггер раскрывать Qt типы сам?
Ну и, как заметили выше, хочется valgrind.anastasiak2512
06.11.2015 15:41Спасибо.
1) Есть давно.
2) Вы про это? Там был воркэраунд с .gdbinit. Не пробовали?
Valgrind — голосуйте за тикет.
slonopotamus
06.11.2015 12:21+2Кстати, о получении CMake проекта для работы с UE4 в CLion читайте статью на английском от нашего коллеги
1. Необходимость патчить билд-систему не выглядит как win. Ваш коллега отправил эти изменения в виде pull request'а в движок?
2. Научите его, пожалуйста, использовать diff'ы. Хуже текстового описания модификаций файлов только скриншоты с этими самыми модификациями.
3. Получившееся на выходе шевелится с хоть сколько-нибудь приемлемой скоростью? Мы пробовали CLion + UE4 весной и пользоваться этим было невозможно, одно открытие проекта занимало несколько десятков минут.
anastasiak2512
06.11.2015 12:481. Да, именно это он и сделал. В мастере уже должно быть вроде.
2. Пост писался немного на ходу. Есть определенные недостатки. Думаю, мы вскоре напишем более подробно в нашем блоге CLion. Тем более, есть обновления и скоро будет видео запись выступления на конференции на эту тему.
3. Во-первых, сейчас по перфомансу стало сильно лучше в самом CLion. Во-вторых, стоит увеличить xmx. Дефолтовых 2Gb даже самому UE4 не хватит на большом проекте. Рекомендуем хотя бы 3.slonopotamus
06.11.2015 13:21Вы про этот коммит? https://github.com/EpicGames/UnrealEngine/commit/93bd7592291aba1efc1abef31e96b683bf6b1578
Взял 4.10, в который коммит уже включен, попробовал. Не работает от слова совсем, все файлы в проекте показываются серым, ctrl+n не находит ничего.
Применил сверху https://github.com/EpicGames/UnrealEngine/pull/1668 Стало лучше by a negligible margin. CLion осознал где файлы моего проекта, но про движковые инклюды по-прежнему ничего не знает.
Дальше, сборка. Если UBT запускался с ключом -rocket (как это будет при использовании предсобранного движка), сбилдить не удаётся ничего. Если без -rocket, то таргеты «Foo-Editor-Bar» на самом деле билдят «Foo-Bar».
Также непонятно как запускать. CLion хочет чтобы я что-то прописал в поле «Executable» в билд-конфигурации.
В общем мне кажется что оно никак не работает. ЧЯДНТ?slonopotamus
06.11.2015 13:33UPDATE: Я понял почему Clion не видит движковые инклюды. UE4_ROOT_PATH за пределами корня Clion'овского проекта.
fsmorygo
06.11.2015 14:19У меня CLion на OS X все отлично видит даже если движковые инклюды за project root.
set(UE4_ROOT_PATH /Users/Shared/UnrealEngine/git) set(GAME_PROJECT_FILE "/Users/fsmorygo/TurnipRun/TurnipRun.uproject") set(BUILD mono ${UE4_ROOT_PATH}/Engine/Binaries/DotNET/UnrealBuildTool.exe ) set(GAME_ROOT_PATH "/Users/fsmorygo/TurnipRun")
fsmorygo
06.11.2015 14:14Добрый день. Сразу задам вопрос, лежит ли рядом с CMakeFiles.txt файл postinclude.cmake со следующим содержимым?
add_executable(FakeTarget ${SOURCE_FILES})
Да, с -rocket проблема еще не решена, я еще в процессе. Когда доделаю, оформлю пулл-реквест и опубликую пост об этом. Без -rocket у меня все собиралось хорошо, можно ли взглянуть на кейс, при котором билдится не тот таргет?
Также, что касается скорости индексирования, процесс можно ускорить двумя способами:
1) Закомментировать в CMakeLists.txt лишние таргеты для того, чтобы CLion из не обрабатывал.
2) Добавить в файл preinclude.cmake строку (Debug можно заменить на что-нибудь более подходящее при желании):
set(CMAKE_CONFIGURATION_TYPES Debug CACHE TYPE INTERNAL FORCE )slonopotamus
06.11.2015 15:12Давайте уточним, нужен ли https://github.com/EpicGames/UnrealEngine/pull/1668? Как я понимаю, именно оно добавляет обработку postinclude.cmake. Повторюсь, я сейчас на 4.10.
лежит ли рядом с CMakeFiles.txt файл postinclude.cmake
Нет, кто его должен был создать? Положил ручками. По-моему изменилось ничего.
можно ли взглянуть на кейс, при котором билдится не тот таргет?
Выбираю run configuration «GameEditor», жмякаю в CLion Run->Build. Вижу в логе вывод UBT:
Creating makefile for Game (no existing makefile)
Ну и оно действительно соберёт бинарь с игрой, а не редактор.
Закомментировать в CMakeLists.txt лишние таргеты для того, чтобы CLion из не обрабатывал.
Не тянет на продакшен-решение.
set(CMAKE_CONFIGURATION_TYPES Debug CACHE TYPE INTERNAL FORCE )
Даже с этим cmake 4 минуты жуёт проц при импорте проекта.
В общем заставить CLion понять где лежат движковые хедеры не выходит.
set(UE4_ROOT_PATH /home/marat/production/ue4) set(GAME_PROJECT_FILE "/home/marat/production/game/Game.uproject") set(BUILD mono ${UE4_ROOT_PATH}/Engine/Binaries/DotNET/UnrealBuildTool.exe ) set(GAME_ROOT_PATH "/home/marat/production/game")
P.S. Каким тегом вы подсвечиваете код?slonopotamus
06.11.2015 15:25Выбираю run configuration «GameEditor», жмякаю в CLion Run->Build
Ооо, я кажется понял. Кнопка Run->Build билдит ВСЁ, а не выбранный run configuration? А как сбилдить только выбранное, но не запускать его?
stigger
09.11.2015 13:37Нет, кнопка Build билдит только выбранный run configuration. Там в окошке с билд-логом можно сверху посмотреть фактическую команду, которая была использована для запуска сборки.
fsmorygo
09.11.2015 14:58Насколько я понимаю, сборка GameEditor все равно приведет к построению Game.app
Чтобы запустить сам редактор, все равно надо запускать
<UE4_ROOT_PATH>/Engine/Binaries/Mac/UE4Editor.app "<GAME_PATH>/Game.uproject" -debug
По крайней мере, Xcode делает именно так.
joedm
07.11.2015 18:11Две вещи, которые меня держат на CodeBlocks:
1. Нет Memory View и дизассемблера кода при отладке.
2. Если используется fork(), то child process не отлаживается. Приходится делать attach to process либо прописывать параметр в .gdbrc. Сделайте в настройках переключатель Follow fork mode: parent/child или дайте возможность передавать параметры в gdb минуя .gdbrc.
Спасибо.anastasiak2512
09.11.2015 00:52Вам спасибо за отзыв.
2. Про fork() проблема известна. Собираемся, конечно, делать, просто руки никак не дойдут пока (можно проголосовать за тикет или просто подписаться, чтобы следить за прогрессом).
Attach to local process скоро должен появиться. Очень хотели сделать его к 1.2, но не сложилось по разным причинам. Планируем, что войдет в след. релиз.
1. Да, пока это только в самой консоли дебагера через команды (GDB или LLDB) доступно. Есть соответствующие реквесты в трекере, ждут своей очереди:
CPP-1748
CPP-3567
wibotwi
10.11.2015 07:05Поддержку модулей внутри одного проекта так и не решились делать?
Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Ну и конечно очень хочется sftp keepalive в remote dev плагине, которую уже 6-й год ждём.anastasiak2512
10.11.2015 12:02> Поддержку модулей внутри одного проекта так и не решились делать?
Это вопрос CMake, а не нашей решимости. CLion пока поддерживает только CMake модель, которая устроена как одно большое дерево.
> Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Вы вероятно про Remote Hosts Access плагин? Обдумываем добавить его, пока затормозилось по разным причинам. А Вы пользуетесь им в других наших IDE? Расскажите, как именно, какой сценарий.wibotwi
10.11.2015 16:31CMake тут не причем. Мы же просим свой CMake на каждой модуль. В PyCharm свой PythonPath на каждый модуль и работает это изумительно.
У нас все разработчики сидят на виндоус а код пишут под линукс.
Часть использует cygwin+rsync. Пописал код в CLion, переключился на консоль, скопировал файлы на линукс, переключился на другую консоль, скомпилял и запустил.
Я держу PyCharm настроенный на cpp папку. Пописал код в CLion, переключился на PyCharm, подождал пока он новое соединение откроет за 3 секунды и потом скопирует файлы за 1 миллисекунду.anastasiak2512
10.11.2015 16:42Сейчас в CLion модель — один проект = одно CMake дерево. Хотите несколько, с возможностью кросс-навигации и пр., сделайте агрегирующий CMakeLists.txt и добавьте в него add_subdirectory. Если есть понимание, почему в Вашем случае, это не вариант, опишите, пожалуйста здесь. Заранее спасибо.
Про Remote Hosts Access поняла. Спасибо. Посмотрим, как быстро можем добавить. Трекать прогресс можно здесь.
dMetrius
Скидки к Black Friday или Cyber Monday готовите? На апдейт на подписочную модель по льготным условиям скидки планируете?
anastasiak2512
Кроме скидок для существующих пользователей, интересного предложения All products для тех, кто использует более одной IDE от JetBrains, и непосредственно самой новой модели, пока что больше ничего не запланировано.