Комментарии 57
Не удивив редактора CMake Cache, подумал что это баг, а оказывается это фитча. Хорошо что с выносом каталога сборки, для редактирования кеша можно cmake-gui использовать.
Без дерактора, как это сделано в cmake-gui или (мой комит) в Qt Creator, неудобно пользоваться фичей:
- https://blog.kitware.com/constraining-values-with-comboboxes-in-cmake-cmake-gui/
- http://blog.bethcodes.com/cmake-tips-tricks-drop-down-list
- https://cmake.org/cmake/help/v3.3/prop_cache/STRINGS.html
А ещё, вышел CMake 3.7, а с ним появилась поддержка Server Mode. Начальная поддержка появилась в Qt Creator на мастер-ветке. У вас что-то в этом направлении планируется?
Что-то пропустил, но там CMake сейчас занимается только Tobias Hunger :-) Но он как-то не совсем удобно сделал, сейчас мы с ним подпиливаем, я ему портирую свои изменения из CMakeProjectManager2. Главная идея: пока устройства дерева лучше чем в KDevelop никем не предложено. У вас просто дерево, в QtC только файлы из CMake — ни таргетов. В KDevelop удобнее сделано. Но Сервер у него уже работает (можно потыкать в git сборках).
Обидно, что в выходные оплатил подписку на год, а через пару дней вышла новая версия — у меня теперь в качестве постоянного фолбека 2016.2.
Нельзя ли с этим что-то сделать? :)
Просто сделайте возможность собирать Kit — по сути, группировка компиляторов, параметров сборки и т.п., которую можно использовать для конкретной билд-конфигурации. Этим можно решить вопрос сборки произвольным компилятором, а не дефолтным в системе.
Упреждая: отписываться в трекере, скорее всего не буду, так как не пользуюсь продуктом (собственно из-за полной невозможности использования не для десктоп разработки в рамках компилятора по-умолчанию). Ну и показать кусок кода мне проще, чем описать полностью хотелку. Поэтому, пока, лучший выбор для меня — QtC ;-) А так — успехов!
Для кросс-компиляции есть CMAKE_TOOLCHAIN_FILE
Это понятно. И способа как минимум 4:
- Через инит-кеш (cmake -C initial-cache-script)
- Через переменные окружения
- Через тулчейн-файл
- Через параметры командной строки
А как среда, как парсер на это реагирует? У меня коллеги пытаются использовать Clion для работы над проектом, так от проблемы с тем что цепляются параметры (типа путей поиска заголовочников по-умолчанию) дефолтного компилятора, а не того, что в тулчейне прописан несколько страдают. Или IDE подцепляет параметры компилятора, sysroot, а они делают что-то не так?
Ну и остаётся вопрос удобства, когда таких тулчейнов несколько (и не обязательно для кросс-сборки, просто версии компилятор разные) и нужно для нескольких проектов иметь возможность меж ними переключаться. Как я понимаю, сейчас можно проект настроить только на что-то одно (даже указав компилятор и прочие параметры одним из вышеперечисленных способов).
Кроме того: настройка используемого cmake для данного набора (редко, но иногда нужная фича), отладчика.
Ну и билд конфигурации с разными параметрами сборки тоже не хватает, с возможностью между ними переключаться.
Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать. Если проблемы, то лучше в саппорт или трекер написать — будем разбираться.
Что касается первой части, то вообще и переменные окружения, и тулчейн файл, и параметры командной строки должны работать.
Я правильно понял, что парсер должен смочь подхватить параметры компилятора (пути по умолчания для заголовочников, набор предобъявленных констант), если компилятор не системный, а задан, пусть — тулчейн-файлом?
qmake — планируем, но не ясно пока, когда именно
UI designer — вряд ли, наши инструменты нацелены на работу с кодом скорее
Qt Visual Studio Tools — штука удобная, не спорю. И, наверное, в качестве плагина к CLion ее сделать можно. Но в ближайшее время, вряд ли мы сможем выделить на это ресурсы команды. Но если кто-то в коммьюнити захочет что-то подобное сделать (API то открытый), мы будем рады помочь/подсказать по мере возможностей.
— отображение Qt-ных типов в отладчике
— понимание парсером механизма 'signals/slots', правильное автодополнение для QObject::connect и подобных.
— редактор QML.
Сейчас для каждого переключения нужно лезть в меню, переключать там И переключать таргет. Можно как-то настроить переключение в одном месте — выбором таргетов или, на худой конец, только переключением настроек (а таргет бы подхватывал нужный режим сам)?
Я разрабатываю с использованием JNI. Мне удобно было бы использовать один проект в двух ide (idea, clion), однако обе ide для своей работы создают папку .idea, что мешает работе одной из них. Что посоветуете?
Про список таргетов — вообще идея прикольная. Вроде и правда что-то такое обсуждали уже тут. А закинете вот сюда с описанием что-как-зачем? Подумаем над запросом более обстоятельно.
Пара фич, которые могут помочь (не решение, но возможный workaround):
- В списках обычно работает live search, то есть если фокус на списке, то можно начать печатать подстроку или первые буквы из частей названия (отфильтруются все таргеты, кроме содержащих введенную подпоследовательность в названиии)
- Action "Select Run/Debug configuration" можно назначить на хоткей, чтобы не кликать мышкой в combo-box, еще есть аналогичные экшены "Run..." и "Debug..." (выбрать конфигурацию и сразу запустить)
Хы, ты забыл сказать: как это сделано в KDevelop ;-) В QtC для CMake 3.7 сделали примерно так же — как же неудобно (пока?). Когда в LLVM открыл директорию с тестами, там овер-дохрена таргетов как вывалилось… Аж жуть.
Data formatters из ~/.lldbinit должны подцепляться.
Возможно, я невнимательно прочитал список изменений в 2016.2, но хотелось бы узнать, почему вырезали эту возможность, есть ли какая-то альтернатива и вернут ли этот функционал в дальнейшем?
Спасибо!
Релиз CLion 2016.3: улучшения поддержки C11, C++11 и C++14, изменения в работе с проектной моделью CMake и многое другое