Комментарии 40
НЛО прилетело и опубликовало эту надпись здесь
За google test спасибо огромное. Можно еще запилить поддержку https://github.com/google/benchmark?
Добавьте, пожалуйста, в трекер запрос. Оценим, что и когда можем сделать.
Хотелось бы поддержку Valgrind, gprof и импорт/поддержку других систем сборки.
И баг с буфером обмена очень противный. Но вы конечно, медленно но верно движетесь к идеалу. Спасибо вам за это.
И баг с буфером обмена очень противный. Но вы конечно, медленно но верно движетесь к идеалу. Спасибо вам за это.
Спасибо за комментарий и за приятный фидбек.
Соответствующие запросы есть в трекере, там можно за ними следить:
А что за баг с буфером обмена, напомните? Может, есть ссылка на трекер?
Соответствующие запросы есть в трекере, там можно за ними следить:
А что за баг с буфером обмена, напомните? Может, есть ссылка на трекер?
Запрос на gprof я и запостил ;)
Valgrind, как и Makefile(а заодно Qt, Visual Studio, Autotools) это один из самых популярных фич-реквестов уже давно. Но и объем работы для них, очевидно, немаленький, поэтому продолжаем ждать.
Баг с буфером обмена.
Valgrind, как и Makefile(а заодно Qt, Visual Studio, Autotools) это один из самых популярных фич-реквестов уже давно. Но и объем работы для них, очевидно, немаленький, поэтому продолжаем ждать.
Баг с буфером обмена.
Понятно. Спасибо за ссылку и напоминание. Посмотрим, что можем сделать.
Можете заодно пояснить мотивацию политики «всё что связано с VS (toolchain, projects) — только ReSharper и никак не Clion»? Кроме желания продавать два продукта естественно.
Я получил как-то ответ, что Clion нацелен на кросс-платформенную разработку, и VS тут не в тему. Но
а). Не кросс-платформенные инструменты (Valgrind, LLDB) не получили такую же реакцию
б). VS не исключает кросс-платформенность. Тот же Cmake генерирует VS проекты, а V8, например, под Win больше ничем не собрать.
Я получил как-то ответ, что Clion нацелен на кросс-платформенную разработку, и VS тут не в тему. Но
а). Не кросс-платформенные инструменты (Valgrind, LLDB) не получили такую же реакцию
б). VS не исключает кросс-платформенность. Тот же Cmake генерирует VS проекты, а V8, например, под Win больше ничем не собрать.
В условиях наличия ReSharper C++ пока не понятно, зачем бы сейчас тратить ценные ресурсы команды на VS toolchain в CLion. То есть не то, чтобы мы об этом не думали вообще. Просто пока это задача за рамками проекта. Есть много куда как более важных.
За рамками проекта или не в приоритете?
Зачем — как раз по-моему вполне очевидно. Хочется одну IDE для все проектах на плюсах. С той же целью у вас и просят поддерживать кучу вещей: Makefile, Qt, Arduino, cross-compilation, Autotools, VS toolchain, SCons, Gradle, ninja, CUDA, intel compiler, Bazel, GLSL ES — это только с первой страницы, то есть с более-менее большим количеством голосов.
Ну то есть понятно, что вы пытаетесь покрыть максимальную аудиторию, и к тому же выпускать продукты с пересекающейся функциональностью не очень выгодно. Но очень хочется оставить на компьютере CLion единственной IDE. Думаю и вам приятно будет.
Зачем — как раз по-моему вполне очевидно. Хочется одну IDE для все проектах на плюсах. С той же целью у вас и просят поддерживать кучу вещей: Makefile, Qt, Arduino, cross-compilation, Autotools, VS toolchain, SCons, Gradle, ninja, CUDA, intel compiler, Bazel, GLSL ES — это только с первой страницы, то есть с более-менее большим количеством голосов.
Ну то есть понятно, что вы пытаетесь покрыть максимальную аудиторию, и к тому же выпускать продукты с пересекающейся функциональностью не очень выгодно. Но очень хочется оставить на компьютере CLion единственной IDE. Думаю и вам приятно будет.
Мы это понимаем. За рамками — на данный момент. Но то есть совсем не в приоритете пока что) Как Вы верно заметили на первой странице и так много всего. Чуть позже, возможно, мы вернемся к этому вопросу и подумаем, стоит ли нам это делать или есть еще какие-то варианты (вообще они есть, но о них пока рано). Но чтобы никого зря не обнадеживать, пока отвечаем, что за рамками проекта.
CMake
Как обстоят дела с поддержкой Generic projects? Есть проекты которые перевести на CMake сииииильно сложно. В том же QtC есть поддержка т.н. Generic Project Manger, когда ты указываешь директорию, сканируются исходники, просто составляется список, этот список используется для парсера, команду билда можно указать вручную. Ну плюс всякие настроки, типа определения дефайнов, путей поиска заголовочных файлов и т.п., ручное указание бинарника для запуска.
Git операции для бранча собраны теперь в одном меню
с недавных пор в QtC есть отличная фича: при наличии озменений на бранче, при переключении на другой бранч есть возможность сделать Stash изменениям (при этом указывается определённая метка), а при возврате на этот бранч сразу сделать Stash pop этим изменениям. Крайне удобно при работе над несколькими проблемами: нет нужды делать комит для какого-нибудь дебажного изменения. Есть ли что-то подобное в CLion?
И да, что-то не увидел возможности удалённой отладки (актуально для всяких связок типа gdb+openocd). И отладчик можно только один для всех проектов использовать?
Хотя проект для FX3 с моими правилами (https://github.com/h4tr3d/fx3-cmake) переварил нормально :)
Хотя проект для FX3 с моими правилами (https://github.com/h4tr3d/fx3-cmake) переварил нормально :)
Удаленной отладки пока нет. Думаем про нее в рамках вот этой задачи.
Думаю, что сначала появится attach to local process, потом вероятно to remote, а потом уже и до удаленной отладки в широком смысле доберемся. Пока временных интервалов не могу предложить.
Настройки toolchain (в частности отладчика) пока что per IDE, а не per project. То есть можно только в целом сменить выбранный отладчик. Если кажется, что нужно это делать per project, добавьте в трекер, пожалуйста. Мы подумаем.
Думаю, что сначала появится attach to local process, потом вероятно to remote, а потом уже и до удаленной отладки в широком смысле доберемся. Пока временных интервалов не могу предложить.
Настройки toolchain (в частности отладчика) пока что per IDE, а не per project. То есть можно только в целом сменить выбранный отладчик. Если кажется, что нужно это делать per project, добавьте в трекер, пожалуйста. Мы подумаем.
Настройки 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 интересна возможностями рефакторинга.
Сейчас CLion поддерживает только CMake, и планируются другие проектные модели в будущем (типа Makefiles, итд). Generic projects — это фактический означает, что будет свой кастомный формат проекта и UI для его настроек. Мы периодически задумываемся о таком варианте, но кажется, что лучше поддерживать известные форматы. Довольно много настроек придется в противном случае протаскивать в UI, к тому же надо будет изобретать свой велосипед с форматом проекта для IDE. Как-то пока это не выглядит как удобное решение.
Да и можно все тоже сделать заимпортировав проект в CMake прямо в CLion, доуказав стандарт языка, стандартную библиотеку, пр. в файле CMake, сгенерированным IDE, а список сорс-файлов и заголовочные файлы задаются в интерфейсе при импорте и добавляются в файл CMake проекта автоматически при импорте. Недостаток разве что в том, что после этого шага все изменения в CMake уже придется вносить самому.
Да, про изменения в бранче, ровно такой функциональности действительно не хватает (можно повоутить тикет, если кажется, что это надо). Можно либо руками делать stash, либо автоматический smart checkout использовать, но он накатывает изменения и на второй бранч, который чекаутим.
Да и можно все тоже сделать заимпортировав проект в CMake прямо в CLion, доуказав стандарт языка, стандартную библиотеку, пр. в файле CMake, сгенерированным IDE, а список сорс-файлов и заголовочные файлы задаются в интерфейсе при импорте и добавляются в файл CMake проекта автоматически при импорте. Недостаток разве что в том, что после этого шага все изменения в CMake уже придется вносить самому.
Да, про изменения в бранче, ровно такой функциональности действительно не хватает (можно повоутить тикет, если кажется, что это надо). Можно либо руками делать stash, либо автоматический smart checkout использовать, но он накатывает изменения и на второй бранч, который чекаутим.
В CMake есть такая штука, как ExternalProject. С помощью нее можно указать, как собирать и линковаться со сторонним проектом (указывается имя стороннего таргета, которое потом можно юзать в target_link_libraries).
Спасибо за наводку. Поизучаю на досуге.
Да, есть. Правда пока что в CLion есть проблемы по работе с этой конкретной командой. Планируем заняться в ближайшее время. Посмотрим, что можем сделать.
Хорошие новости!
Есть такие вопросы:
1) Поддержка mingw64 уже есть?
2) Научился ли дебаггер раскрывать Qt типы сам?
Ну и, как заметили выше, хочется valgrind.
Есть такие вопросы:
1) Поддержка mingw64 уже есть?
2) Научился ли дебаггер раскрывать Qt типы сам?
Ну и, как заметили выше, хочется valgrind.
Кстати, о получении CMake проекта для работы с UE4 в CLion читайте статью на английском от нашего коллеги
1. Необходимость патчить билд-систему не выглядит как win. Ваш коллега отправил эти изменения в виде pull request'а в движок?
2. Научите его, пожалуйста, использовать diff'ы. Хуже текстового описания модификаций файлов только скриншоты с этими самыми модификациями.
3. Получившееся на выходе шевелится с хоть сколько-нибудь приемлемой скоростью? Мы пробовали CLion + UE4 весной и пользоваться этим было невозможно, одно открытие проекта занимало несколько десятков минут.
1. Да, именно это он и сделал. В мастере уже должно быть вроде.
2. Пост писался немного на ходу. Есть определенные недостатки. Думаю, мы вскоре напишем более подробно в нашем блоге CLion. Тем более, есть обновления и скоро будет видео запись выступления на конференции на эту тему.
3. Во-первых, сейчас по перфомансу стало сильно лучше в самом CLion. Во-вторых, стоит увеличить xmx. Дефолтовых 2Gb даже самому UE4 не хватит на большом проекте. Рекомендуем хотя бы 3.
2. Пост писался немного на ходу. Есть определенные недостатки. Думаю, мы вскоре напишем более подробно в нашем блоге CLion. Тем более, есть обновления и скоро будет видео запись выступления на конференции на эту тему.
3. Во-первых, сейчас по перфомансу стало сильно лучше в самом CLion. Во-вторых, стоит увеличить xmx. Дефолтовых 2Gb даже самому UE4 не хватит на большом проекте. Рекомендуем хотя бы 3.
Вы про этот коммит? 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» в билд-конфигурации.
В общем мне кажется что оно никак не работает. ЧЯДНТ?
Взял 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» в билд-конфигурации.
В общем мне кажется что оно никак не работает. ЧЯДНТ?
UPDATE: Я понял почему Clion не видит движковые инклюды. UE4_ROOT_PATH за пределами корня Clion'овского проекта.
У меня 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")
Добрый день. Сразу задам вопрос, лежит ли рядом с CMakeFiles.txt файл postinclude.cmake со следующим содержимым?
Да, с -rocket проблема еще не решена, я еще в процессе. Когда доделаю, оформлю пулл-реквест и опубликую пост об этом. Без -rocket у меня все собиралось хорошо, можно ли взглянуть на кейс, при котором билдится не тот таргет?
Также, что касается скорости индексирования, процесс можно ускорить двумя способами:
1) Закомментировать в CMakeLists.txt лишние таргеты для того, чтобы CLion из не обрабатывал.
2) Добавить в файл preinclude.cmake строку (Debug можно заменить на что-нибудь более подходящее при желании):
add_executable(FakeTarget ${SOURCE_FILES})
Да, с -rocket проблема еще не решена, я еще в процессе. Когда доделаю, оформлю пулл-реквест и опубликую пост об этом. Без -rocket у меня все собиралось хорошо, можно ли взглянуть на кейс, при котором билдится не тот таргет?
Также, что касается скорости индексирования, процесс можно ускорить двумя способами:
1) Закомментировать в CMakeLists.txt лишние таргеты для того, чтобы CLion из не обрабатывал.
2) Добавить в файл preinclude.cmake строку (Debug можно заменить на что-нибудь более подходящее при желании):
set(CMAKE_CONFIGURATION_TYPES Debug CACHE TYPE INTERNAL FORCE )
Давайте уточним, нужен ли https://github.com/EpicGames/UnrealEngine/pull/1668? Как я понимаю, именно оно добавляет обработку postinclude.cmake. Повторюсь, я сейчас на 4.10.
Нет, кто его должен был создать? Положил ручками. По-моему изменилось ничего.
Выбираю run configuration «GameEditor», жмякаю в CLion Run->Build. Вижу в логе вывод UBT:
Ну и оно действительно соберёт бинарь с игрой, а не редактор.
Не тянет на продакшен-решение.
Даже с этим cmake 4 минуты жуёт проц при импорте проекта.
В общем заставить CLion понять где лежат движковые хедеры не выходит.
P.S. Каким тегом вы подсвечиваете код?
лежит ли рядом с 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. Каким тегом вы подсвечиваете код?
Выбираю run configuration «GameEditor», жмякаю в CLion Run->Build
Ооо, я кажется понял. Кнопка Run->Build билдит ВСЁ, а не выбранный run configuration? А как сбилдить только выбранное, но не запускать его?
Нет, кнопка Build билдит только выбранный run configuration. Там в окошке с билд-логом можно сверху посмотреть фактическую команду, которая была использована для запуска сборки.
Насколько я понимаю, сборка GameEditor все равно приведет к построению Game.app
Чтобы запустить сам редактор, все равно надо запускать
По крайней мере, Xcode делает именно так.
Чтобы запустить сам редактор, все равно надо запускать
<UE4_ROOT_PATH>/Engine/Binaries/Mac/UE4Editor.app "<GAME_PATH>/Game.uproject" -debugПо крайней мере, Xcode делает именно так.
Две вещи, которые меня держат на CodeBlocks:
1. Нет Memory View и дизассемблера кода при отладке.
2. Если используется fork(), то child process не отлаживается. Приходится делать attach to process либо прописывать параметр в .gdbrc. Сделайте в настройках переключатель Follow fork mode: parent/child или дайте возможность передавать параметры в gdb минуя .gdbrc.
Спасибо.
1. Нет Memory View и дизассемблера кода при отладке.
2. Если используется fork(), то child process не отлаживается. Приходится делать attach to process либо прописывать параметр в .gdbrc. Сделайте в настройках переключатель Follow fork mode: parent/child или дайте возможность передавать параметры в gdb минуя .gdbrc.
Спасибо.
Вам спасибо за отзыв.
2. Про fork() проблема известна. Собираемся, конечно, делать, просто руки никак не дойдут пока (можно проголосовать за тикет или просто подписаться, чтобы следить за прогрессом).
Attach to local process скоро должен появиться. Очень хотели сделать его к 1.2, но не сложилось по разным причинам. Планируем, что войдет в след. релиз.
1. Да, пока это только в самой консоли дебагера через команды (GDB или LLDB) доступно. Есть соответствующие реквесты в трекере, ждут своей очереди:
CPP-1748
CPP-3567
2. Про fork() проблема известна. Собираемся, конечно, делать, просто руки никак не дойдут пока (можно проголосовать за тикет или просто подписаться, чтобы следить за прогрессом).
Attach to local process скоро должен появиться. Очень хотели сделать его к 1.2, но не сложилось по разным причинам. Планируем, что войдет в след. релиз.
1. Да, пока это только в самой консоли дебагера через команды (GDB или LLDB) доступно. Есть соответствующие реквесты в трекере, ждут своей очереди:
CPP-1748
CPP-3567
Поддержку модулей внутри одного проекта так и не решились делать?
Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Ну и конечно очень хочется sftp keepalive в remote dev плагине, которую уже 6-й год ждём.
Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Ну и конечно очень хочется sftp keepalive в remote dev плагине, которую уже 6-й год ждём.
> Поддержку модулей внутри одного проекта так и не решились делать?
Это вопрос CMake, а не нашей решимости. CLion пока поддерживает только CMake модель, которая устроена как одно большое дерево.
> Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Вы вероятно про Remote Hosts Access плагин? Обдумываем добавить его, пока затормозилось по разным причинам. А Вы пользуетесь им в других наших IDE? Расскажите, как именно, какой сценарий.
Это вопрос CMake, а не нашей решимости. CLion пока поддерживает только CMake модель, которая устроена как одно большое дерево.
> Что насчет поддержки remote development плагина, который идет в составе всех Jetbrains IDE кроме CLion?
Вы вероятно про Remote Hosts Access плагин? Обдумываем добавить его, пока затормозилось по разным причинам. А Вы пользуетесь им в других наших IDE? Расскажите, как именно, какой сценарий.
CMake тут не причем. Мы же просим свой CMake на каждой модуль. В PyCharm свой PythonPath на каждый модуль и работает это изумительно.
У нас все разработчики сидят на виндоус а код пишут под линукс.
Часть использует cygwin+rsync. Пописал код в CLion, переключился на консоль, скопировал файлы на линукс, переключился на другую консоль, скомпилял и запустил.
Я держу PyCharm настроенный на cpp папку. Пописал код в CLion, переключился на PyCharm, подождал пока он новое соединение откроет за 3 секунды и потом скопирует файлы за 1 миллисекунду.
У нас все разработчики сидят на виндоус а код пишут под линукс.
Часть использует cygwin+rsync. Пописал код в CLion, переключился на консоль, скопировал файлы на линукс, переключился на другую консоль, скомпилял и запустил.
Я держу PyCharm настроенный на cpp папку. Пописал код в CLion, переключился на PyCharm, подождал пока он новое соединение откроет за 3 секунды и потом скопирует файлы за 1 миллисекунду.
Сейчас в CLion модель — один проект = одно CMake дерево. Хотите несколько, с возможностью кросс-навигации и пр., сделайте агрегирующий CMakeLists.txt и добавьте в него add_subdirectory. Если есть понимание, почему в Вашем случае, это не вариант, опишите, пожалуйста здесь. Заранее спасибо.
Про Remote Hosts Access поняла. Спасибо. Посмотрим, как быстро можем добавить. Трекать прогресс можно здесь.
Про Remote Hosts Access поняла. Спасибо. Посмотрим, как быстро можем добавить. Трекать прогресс можно здесь.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
CLion 1.2: еще больше возможностей и преимуществ