Pull to refresh

Comments 38

Скажите а есть ли сейчас какой-нибудь способ работать с кодовой базой хромиума или webrtc например? Там gn + ninja.
Я сейчас вручную генерирую здоровенный CMakeLists со всеми хедерами и инклудами и открываю его в clion. Кое как работает, но постоянно надо новые инклуды, исходники, дефайны прописывать. Есть ли другие способы?
А еще можно ли дебажить собраный gn+ninja бинарик в clion? в clion удается дебажить через gdbserver. Можно ли без него(gdbserver)?
Ну дебажить можно подключившись либо удаленно через GDB/GDBserver, либо через attach to local process, если процесс локально запущен
Пока, к сожалению, другого способа нет. Только CMake поддержан.
Ладно cmake, но то, что он еще и на make завязан жестко — очень жаль. ninja значительно быстрее работает…
Мы планируем сделать поддержку ninja генератора. Для этого надо научить CLion понимать формат соответствующих файлов и еще понять, что делать с недостающей информацией. Возможно, придется в ninja положить нужные нам изменения или какой-то обходной путь искать. В общем, мы думаем (активно), но пока решения нет.
Я сегодня статью запостил, что для этого делаю я — может опубликуют в песочнице.
В двух словах, для вас гению через make, а для сборки использую ninja :)

Кстати, есть такая штука kati, которая конвертирует makefile в ninja. Написана Гуглом, используется в Андроиде.

А почему бы автоматически не читать настройки tidy из .clang-tidy?
У меня проверка на tidy делается на каждый push. Специально сделал пару ошибок. Как увидеть результат tidy в CLion? Когда вы его прогоняете (он ведь довольно медленный)?

Еще у вас всплывающие внизу справа уведомления жрут 100% CPU, пока их не закроешь :)
Clang-Tidy работает в фоне, и как закончит, все ошибки из него показываются в редакторе. Выглядит это также, как и ошибки от собственного анализатора кода.

Что значит читать настройки автоматически? Откуда?

Хм, про CPU, а можно скриншот и в идеале CPU snapshot? Мы что-то такого не видели.
CPU кушает gitignore плагин похоже. Плагин сторонний, у него вот есть похожие жалобы на github. Наверное, стоит написать там автору запрос, приложив CPU snapshot.
> Что значит читать настройки автоматически? Откуда?

/Applications/CLion.app/Contents/bin/clang/clang-tidy --help

-config= —
Specifies a configuration in YAML/JSON format:
-config="{Checks: '*',
CheckOptions: [{key: x,
value: y}]}"
When the value is empty, clang-tidy will
attempt to find a file named .clang-tidy for
each source file in its parent directories.
Теперь поняла, о чем речь. Спасибо. Вообще мы много чего еще планируем в этом направлении:


Ваше предложение тоже где-то рядом. По-хорошему, наверное, нужен способ и читать настройки из самого clang-tidy, и уметь задавать их в IDE независимо от того, что в command line инструменте настроено.
Вторая ссылка — приватная :)

tidy работает, есть еще пара вопросов.
Где можно посмотреть, что процесс идет (это глаз справа вверху?)
Можно ли отключить ваш встроенный анализатор и оставить только tidy и проверку синтаксиса. А то, ваш анализатор C++17 не понимает (в частности инициализацию свойств через '='), и генерит ложные срабатывания — приходится на него забивать.
Упс, и правда. Но в общем самую правильную ссылку коллега написал — https://youtrack.jetbrains.com/issue/CPP-9129.

Встроенный анализатор отключается в настройках Settings | Editor | Inspections | C/C++, но есть два типа false-positive — от анализатора и от парсера кода, второй — не отключается. К сожалению, C++17 пока поддержан очень немного, но мы планируем работу в этом направлении.
У нас поистине наполеоновские планы в области отладки в CLion

Надеюсь, среди них есть и поддержка Qt в ближайших релизах. Очень уж колючий кактус с разработкой в CLion и отладкой в QtCreator…

P.S. Те, для кого это тоже важно, могут проголосовать за это по ссылке выше.
Забандлить эти pretty-printers к себе мы не можем по лицензионным соглашениям, но сделать удобный интерфейс для выбора их и использования в CLion в целом планируем (наверное, даже в ближайшем релизе).
А прямо сейчас их можно как-то неудобно добавить? Я вижу какие-то советы в issue, но опыта не хватает, чтобы понять насколько они рабочие, не говоря уже про следование им. Сделал как советовали в последнем комменте, но это извращение, а не отладка :)
Последний раз, когда мы смотрели, вроде через .gdbinit работало. Перепроверим.
Возникает ошибка, про неё уже писали.
Traceback (most recent call last):
File "", line 1, in File "/opt/qt/Tools/QtCreator/share/qtcreator/debugger/gdbbridge.py", line 36, in import tempfile
File "/home/ukolov/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/171.4694.31/bin/gdb/lib/python2.7/tempfile.py", line 35, in from random import Random as _Random
File "/home/ukolov/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/171.4694.31/bin/gdb/lib/python2.7/random.py", line 48, in from binascii import hexlify as _hexlify
ImportError: No module named binascii
/home/ukolov/.gdbinit:2: Error in sourced command file:
Error while executing Python code.
Да, в тикете такая же ошибка по сути. Мы посмотрим и отпишемся в тикете, как будут новости. Спасибо.
Входит ли в ваши наполеоновские планы Memory View (https://youtrack.jetbrains.com/issue/CPP-3567)?
Да, этот тикет он как минимум в топ-10 тикетов по дебагеру, которые мы очень хотим сделать. Но пока что больше шансов, что мы начнем с hex formatting — https://youtrack.jetbrains.com/issue/OC-2305.

К тому же, хочется сначала разобраться с GDB 8.0 и LLDB 5.0. Кстати примерные планы на 2017.3 можно найти тут.
Тоже хороший тикет. Но, черт побери, надоело в консоль дебаггера лазить чтобы только лишь кусок памяти просмотреть.
Пофиксите плиз проблему, что когда изменяешь файл, потом удаляешь изменения, ваша git-интеграция, показывает что он изменён всё равно. Реально неудобно! И не надо, пожалуйста, подобные комменты удалять. Лучше пофиксите багу!
странно, почему-то не отправился комментарий к релизу в блоге. За тикет спасибо, буду следить!
Продукт интересный, но сам бы ни купил (использую рабочую лицензию). В основном пользуюсь QtCreator'ом, и вот почему:
* Поддержка ninja
* Интеграция с valgrind, мелочь а приятно
* В больших проектах часто сторонние библиотеки (общий код нескольких проектов) подключены из директорий за пределами корня проекта. При их правке CLion назойливо кричит что редактируется файл за пределами проекта. Меня раздражает.
* В продолжение последнего пукта, все эти фалы вываливаются в корень дерева проекта, из за этого что бы понять структуру, приходится пользоваться проводником :(
* Нет общего списка ошибок, как вообще так?

Кроме того, дебаггер в моих проектах даже std::string развернуть не может, причем интересно иногда QtCreator умеет разворачивать, иногда CLion.

Жду фиксов указанных проблем, тогда можно будет полностью перейти на CLion :)
В догонку (в конце я жму Enter).
image
CLion
CLion 2017.2.2
Build #CL-172.3968.17, built on August 22, 2017
JRE: 1.8.0_152-release-915-b11 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.10.0-35-generic
  • Ninja — CPP-870 — пока не понятно, когда будет, потому что есть техническая сложность (не полная информация о проекта, отдаваемая ninja), которую мы еще не научились решать. Некоторый workaround от пользователей, тем не менее, существует.
  • Valgrind — сейчас ведется работа над интеграцией memcheck из valgrind
  • То, что CLion говорит, что файл не в проекте, как нам кажется, хорошо, потому что намекает, что никакие рефакторинги работать не будут. Да и не должны вероятно в сторонних то библиотеках. Можно добавить библиотеку в sources проекта (Mark directory as).
  • Под списком ошибок вы подразумеваете code analysis ошибки? Есть, если запустить полный анализ кода на проекте или выбранном скоупе. Так как код анализ работает на лету, то без этого, он показывается, ест-но, на текущем открытом файле.
  • Про std::string есть несколько репортов — CPP-8693 и CPP-6828. Это проблема pretty printers в GDB, можно пока полечить указанным workaround-ом.
Все понятно, ждемс :) Моя структура проекта такая:

* ~/ui-framework/**/**.cpp
* ~/physics-framework/**/*.cpp
* ~/game-1/CMakeLists.txt
* ~/game-2/CMakeLists.txt
* ~/game-3/CMakeLists.txt

Всем кодом владею я. Т.е. «сторонние библиотеки» это тоже часть продукта. Скажем проект игры включает десятки исходных файлов, в то время как фреймворки — тысячи. И у меня пригорает от того что я постоянно вижу это сообщение. Я например, не понимаю почему файлы за директорией CMakeLists.txt считаются вне проекта, они явно указаны в CMakeLists.txt и должны принадлежать проекту как и файлы внутри директории с CMakeLists.txt. Мне кажется это какое-то политическое решение.

Список ошибок — структурированный отчёт о результатах компиляции, как в VS или Esclipse или QtCreator, кажется он везде есть. А вот в CLion нет, или я слепой :) Сейчас я наблюдаю только лог компиляции, который я должен разбирать сам. А каждая ошибка в логе компилятора излишне многословная. Кроме того, ошибки компилятора не помечаются на скроллбаре файла %)
Если библиотеки добавлены в CMakeLists.txt, то должны быть автоматически включены в проект. CMake на проекте без ошибок вызывается при CMake Reload?

CLion не показывает на данный момент ошибки компиляции в таком виде, как VS или Eclipse. Это правда.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
jetbrains.com
Employees
1,001–5,000 employees
Registered

Habr blog