Как стать автором
Обновить

Комментарии 57

Не удивив редактора CMake Cache, подумал что это баг, а оказывается это фитча. Хорошо что с выносом каталога сборки, для редактирования кеша можно cmake-gui использовать.

Мы сейчас еще планируем редактор CMake Cache добавить. Чтобы прямо в редакторе CLion была посветка и другие удобные возможности.

Без дерактора, как это сделано в cmake-gui или (мой комит) в Qt Creator, неудобно пользоваться фичей:



А ещё, вышел CMake 3.7, а с ним появилась поддержка Server Mode. Начальная поддержка появилась в Qt Creator на мастер-ветке. У вас что-то в этом направлении планируется?

Мы как раз на Meeting C++ в Берлине на прошлой недели смогли пообщаться с разработчиками из Qt Creator, которые активно участвуют в разарботке CMake Server. Есть интересные идеи и планы на «попробовать». Когда что-то из этого выйдет в реальном релизе продукта пока сказать сложно. Расскажем, как появится понимание.

Что-то пропустил, но там CMake сейчас занимается только Tobias Hunger :-) Но он как-то не совсем удобно сделал, сейчас мы с ним подпиливаем, я ему портирую свои изменения из CMakeProjectManager2. Главная идея: пока устройства дерева лучше чем в KDevelop никем не предложено. У вас просто дерево, в QtC только файлы из CMake — ни таргетов. В KDevelop удобнее сделано. Но Сервер у него уже работает (можно потыкать в git сборках).

Мы как раз с Тобиасом и общались активно, и несколько его коллег тоже подходили.
CMake Server вот тоже обсуждали, мы планируем на него внимательно посмотреть в блажайшее время.
Действительно, CMake значительно ускорился, спасибо.

Обидно, что в выходные оплатил подписку на год, а через пару дней вышла новая версия — у меня теперь в качестве постоянного фолбека 2016.2.
Нельзя ли с этим что-то сделать? :)
Достаточно будет по окончании текущей продлить ее еще на месяц, чтобы получился год непрерывной оплаты, чтобы получить 2016.3 fallback.
Может неуместно, но спрошу: А планируется ли поддержка разработки для ARM например? Имею виду дебагеры периферии и прочие вкусности (см. например Кейл)
В целом, планируется какая-то поддержка. Но пока никаких конкретных вещей пообещать не могу. Описывайте свои случаи использования в нашем трекере. Мы обязательно над ними поразмыслим.

Просто сделайте возможность собирать Kit — по сути, группировка компиляторов, параметров сборки и т.п., которую можно использовать для конкретной билд-конфигурации. Этим можно решить вопрос сборки произвольным компилятором, а не дефолтным в системе.


Упреждая: отписываться в трекере, скорее всего не буду, так как не пользуюсь продуктом (собственно из-за полной невозможности использования не для десктоп разработки в рамках компилятора по-умолчанию). Ну и показать кусок кода мне проще, чем описать полностью хотелку. Поэтому, пока, лучший выбор для меня — QtC ;-) А так — успехов!

Для кросс-компиляции есть CMAKE_TOOLCHAIN_FILE

Знаю. Более подробно — ниже.

Компилятор и сейчас можно использовать любой. Достаточно указать его в CMake.

Это понятно. И способа как минимум 4:


  • Через инит-кеш (cmake -C initial-cache-script)
  • Через переменные окружения
  • Через тулчейн-файл
  • Через параметры командной строки

А как среда, как парсер на это реагирует? У меня коллеги пытаются использовать Clion для работы над проектом, так от проблемы с тем что цепляются параметры (типа путей поиска заголовочников по-умолчанию) дефолтного компилятора, а не того, что в тулчейне прописан несколько страдают. Или IDE подцепляет параметры компилятора, sysroot, а они делают что-то не так?


Ну и остаётся вопрос удобства, когда таких тулчейнов несколько (и не обязательно для кросс-сборки, просто версии компилятор разные) и нужно для нескольких проектов иметь возможность меж ними переключаться. Как я понимаю, сейчас можно проект настроить только на что-то одно (даже указав компилятор и прочие параметры одним из вышеперечисленных способов).


Кроме того: настройка используемого cmake для данного набора (редко, но иногда нужная фича), отладчика.


Ну и билд конфигурации с разными параметрами сборки тоже не хватает, с возможностью между ними переключаться.

Ага, кейс понятен. Мы его даже вот тут обсуждали. Можно оставить описание своего случая тамже.

Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать. Если проблемы, то лучше в саппорт или трекер написать — будем разбираться.
Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать.

Я правильно понял, что парсер должен смочь подхватить параметры компилятора (пути по умолчания для заголовочников, набор предобъявленных констант), если компилятор не системный, а задан, пусть — тулчейн-файлом?

Если компилятор корректно через CMake передается и он GCC/clang-base, то CLion сможет корректно получить всю информацию от компилятора, включая compiler-predefined macros и другое. Если же компилятор отличается или с каким-то хитрыми патчами, то нам известны случаи, когда есть проблемы в парсере. Но тут надо разбираться в каждом конкретном таком случае и лучше нас об этом известить через саппорт или трекер.

Большое спасибо за информацию!

Будет ли когда нибудь введена поддержка msvc? Как в QtCcreator к примеру.
Да, планируем. Пока не могу сказать, когда именно. Как решим, опубликуем планы на следующий релиз и там будет видно.
О, это шикарно. Спасибо большое за такой продукт.
Вам спасибо за отзыв.
Хочу полную интеграцию с Qt и справкой!
qmake? UI designer? Что именно вы понимаете под интеграцией?
Логично предположить, не меньше чем это сделано с visual studio.
Как нам сейчас это видится:

qmake — планируем, но не ясно пока, когда именно
UI designer — вряд ли, наши инструменты нацелены на работу с кодом скорее

Qt Visual Studio Tools — штука удобная, не спорю. И, наверное, в качестве плагина к CLion ее сделать можно. Но в ближайшее время, вряд ли мы сможем выделить на это ресурсы команды. Но если кто-то в коммьюнити захочет что-то подобное сделать (API то открытый), мы будем рады помочь/подсказать по мере возможностей.
А с проектами на Qt он позволяет работать?
нет, qmake пока не поддержан — CPP-318
Я думаю что начать следовало бы не с QMake, а с других Qt-specific вещей:
— отображение Qt-ных типов в отладчике
— понимание парсером механизма 'signals/slots', правильное автодополнение для QObject::connect и подобных.
— редактор QML.
Да, эти задачи есть на самом деле в нашем трекере и мы про них помним. Спасибо за напоминание!
Да, перевести проект с QMake на CMake не очень сложно, а вот то, что дебажить приходится через QtCreator — это сильно мешает.
Да, реквест есть. Напомню команде про него еще раз — посмотрим, что и когда можно сделать. Сейчас могу предложить только workaround — загрузить pretty printers через .gdbinit. Они включены в поставку qt creator.
Можно работать, но только если перевести проект на cmake.
Скажите, а как теперь быстро переключаться между Debug и Release сборками?
Сейчас для каждого переключения нужно лезть в меню, переключать там И переключать таргет. Можно как-то настроить переключение в одном месте — выбором таргетов или, на худой конец, только переключением настроек (а таргет бы подхватывал нужный режим сам)?
К сожалению, быстро сейчас никак. Пришлось этим пожертвовать в угоду экономии места и времени загрузки CMake на проекте. Но мы планируем вернуть удобный способ переключения в рамках вот этого запроса.
Подскажите как мне справиться следующей проблемой:
Я разрабатываю с использованием JNI. Мне удобно было бы использовать один проект в двух ide (idea, clion), однако обе ide для своей работы создают папку .idea, что мешает работе одной из них. Что посоветуете?
Да, проблема известная. К сожалению, хорошего решения предложить пока не могу. CLion когда-нибудь появится в виде плагина к IntelliJ IDEA, но пока на это нет свободных ресурсов команды. Да и проблему с конфликтами настроек разных наших IDE хотели поправить, но как-то тоже пока не сложилось. Спасибо, что напомнили о ней! Надо будет еще раз обсудить, что мы можем сделать.

Вы клевые, спасибо, отличное обновление! Семантическую подсветку давно ждал, приятно видеть.


Одна мелочь, правда, есть. Я в прошлый раз в комментариях уже говорил, но как-то не договорил, так что ещё раз попробую.


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


Так вот, было бы очень круто, если бы список таргетов, задаваемый конкретным CMakeLists.txt, был бы где-то рядом с этим CMakeLists.txt (например, отображался в виде этаких псевдофайлов в дереве слева прям под папками, или по клику на папку, содержащую CMakeLists.txt). Как смотрите на такое дело?

А, и ещё. ninja-генератор для CMake поддерживаете, или только мейкфайлы?

Пока нет, но планируем добавить. Надеюсь, в каком-то из 2017.x сможем сделать.
Спасибо большое! Передам команде.

Про список таргетов — вообще идея прикольная. Вроде и правда что-то такое обсуждали уже тут. А закинете вот сюда с описанием что-как-зачем? Подумаем над запросом более обстоятельно.
0xd34df00d И поделитесь номером тикета, я плюсану. У меня тоже есть проект с >200 таргетов, и работать с ним, мягко говоря, не очень.

Пара фич, которые могут помочь (не решение, но возможный workaround):


  • В списках обычно работает live search, то есть если фокус на списке, то можно начать печатать подстроку или первые буквы из частей названия (отфильтруются все таргеты, кроме содержащих введенную подпоследовательность в названиии)
  • Action "Select Run/Debug configuration" можно назначить на хоткей, чтобы не кликать мышкой в combo-box, еще есть аналогичные экшены "Run..." и "Debug..." (выбрать конфигурацию и сразу запустить)
Ага, спасибо за идеи. Подумаем.

Хы, ты забыл сказать: как это сделано в KDevelop ;-) В QtC для CMake 3.7 сделали примерно так же — как же неудобно (пока?). Когда в LLVM открыл директорию с тестами, там овер-дохрена таргетов как вывалилось… Аж жуть.

Да, как раз планируем после этого релиза посмотреть на эту проблему.
А нет планов на счет поддержки кастомного lldb, или хотя бы возможности передавать в текущим свой .lldbinit?
На какой платформе? Ну и интересен юз кейс. Что именно хочется таким образом получить?
Меня интересует mac. lldb очень плохо раскручивает классы Qt, вплоть до того, что содержимое даже QString не видно в переменных в отладке. Через initlldb это можно настроить, но как подсунуть во встроенный lldb эту настройку я не нашел
Как уже коллега мой ответил, .lldbinit должен сработать как workaround. А вообще про рендеринг Qt типов в отладчике есть реквест. Как раз напомнила про него команде.
Не конкретизировались ли ваши планы по добавлению поддержки makefiles? Тикету на youtrack уже сто лет в обед. Третий по популярности, кстати.
Тикет и правда довольно популярный. Но пока что нам кажется, что другие задачи важнее. Например, изменения по CMake, которые критичны в частности для текущих пользователей продукта. Но мы все же надеемся в следующем году поразмысить над альтернативными проектными моделями в CLion, а может и даже возможностью открывать любой проект, в независимости от проектной модели.
Мне не очень часто доводится использовать CLion, но заметил, что с версии 2016.2 (именно с неё) в дебаге больше нельзя посмотреть массив по указателю целиком, отображается только первый элемент (пропал «Double click to see more items»).
Возможно, я невнимательно прочитал список изменений в 2016.2, но хотелось бы узнать, почему вырезали эту возможность, есть ли какая-то альтернатива и вернут ли этот функционал в дальнейшем?
Спасибо!
Похоже оно раньше работало «случайно» и сломалось в 2016.2. Запрос на такую возможность есть у нас в трекере. Там же описан workaround, пока не реализована возможность. Ну и посмотрим, куда можно в очереди эту задачу поставить — согласна, что важная штука. Спасибо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.