KDevelop 5.6

Годная IDE, использовал её для C++ до появления лицензии от Jetbrains.

Встроенные заметки выглядят вкусно, надо пощупать.

Кто-нибудь кроме царя этим пользуется? Поняши пишут в Qt Creator’е.

Кто-нибудь кроме царя этим пользуется?

Царь же всё равно ничего толком не программирует, не? Ему же скучно этим заниматься.

Оно ещё шевелится. Рад за них.

Поняши пишут в Qt Creator’е.

Ну поняшам только в QtC и писать. Оно же жирное, кривое и неповоротливое (и при этом всём бесполезное, в отличие от того же CLion).

В какой-то момент времени у KDevelop была лучшая реализация анализа C++-ного кода (по крайней мере среди F/OSS). А фича семантической раскраски так и до сих пор по-моему уникальна.

Неплохо, неплохо. Давно уже не юзаю, но негативных воспоминаний нет.

жирное

Не жирнее какой-нибудь поделки на жаве от JetBrains.

В какой-то момент времени у KDevelop была лучшая реализация анализа C++-ного кода (по крайней мере среди F/OSS).

A long time ago in a galaxy far, far away….

Вот только сегодня все эти самописные парсеры и анализаторы C/С++ канули в лету, что у Qt Creator, что у KDevelop.

Оно уже умеет LSP?

Вот только сегодня все эти самописные парсеры и анализаторы C/С++ канули в лету, что у Qt Creator, что у KDevelop.

Ты же понимаешь, да, что между AST и экраном в IDE есть ещё некая логика, и она бывает разного качества? Не всё можно заменить clang-ом.

жирное

Не жирнее какой-нибудь поделки на жаве от JetBrains.

А ты до конца предложение дочитай.

Оно же жирное, кривое и неповоротливое (и при этом всём бесполезное, в отличие от того же CLion).

Вбросил, так вбросил. На работе проект в CLion всосаться не смог, вся память вытекла (у меня всего 16Гб), а QtC переварил и позволил работать. С Embedded и удалённой отладкой на устройствах в самых диких сценариях оно пока CLion рвёт (конкретно сейчас девайс в Оттаве, а я во Владивостоке, 1.5 года назад ваял и отлаживал код для R&D проекта под Microblaze, плата там же, в Оттаве была). Удобный способ указывать настройки конфигурации CMake. В общем, каким бы г-ном QtC не был бы, но в мелочах, особенно не для Desktop разработки, он утирает нос CLion.

Кстати, сразу выключал её в KDevelop. Что-то там с цветами в некоторых темах: код становился нечитаемым. Да и в глазах рябить начинало. Но это чистой воды имхо: выключатель сделали, и то хорошо.

Все как то кривое и недоделанное, в CMake ошибки не выводятся нормально, к месту не перейти, нормального дерева проекта нету. Вылетает постоянно, автодополнение тормозит.

На работе проект в CLion всосаться не смог, вся память вытекла (у меня всего 16Гб), а QtC переварил и позволил работать.

всего 16Гб

Тут надо скастовать ChALkeR :)

С Embedded и удалённой отладкой на устройствах в самых диких сценариях оно пока CLion рвёт (конкретно сейчас девайс в Оттаве, а я во Владивостоке, 1.5 года назад ваял и отлаживал код для R&D проекта под Microblaze, плата там же, в Оттаве была).

С этого места поподробнее. Я, конечно, прямо такими извращениями не занимался, но отлаживать микроконтроллеры в нём вполне отлаживал.

Удобный способ указывать настройки конфигурации CMake.

Вау, оно уже в CMake научилось? вот_это_поворот.

Ты же понимаешь

Я не совсем понимаю, где ты жирность Qt Creator увидел? Что быстрее него для C++? Они оба, что KDevelop, что Qt Creator – быстрые в сравнении с Java IDE вроде Eclipse CDT, NetBeans и CLion.

Заметил, что Qt Creator весьма неплохо набрал популярность в Embedded-сегменте, где всегда балом правили либо переделки Eclipse CDT, либо проприетарщина от Keil/IAR. Даже на ЛОРе встречаю людей, которые для Embedded юзают не только Qt Creator, но и QBS, например. Интересно, с чем это связано.

Кстати, сразу выключал её в KDevelop. Что-то там с цветами в некоторых темах: код становился нечитаемым. Да и в глазах рябить начинало. Но это чистой воды имхо: выключатель сделали, и то хорошо.

Солидарен. Семантическая подсветка довольно спорная фича, превращающая код в «новогоднюю ёлку» и часто отвлекающая, а не помогающая при чтении. Но согласен, это ИМХО, кому-то заходит. Помнится, Царь от неё был в восторге :D

Мне и стоковая схема подсветки синтаксиса в Qt Creator сильно цветастой видится. Идеалом для себя считаю схему из IntelliJ IDEA: подсвечивается лишь самое важное и не слишком броскими цветами.

Кто-нибудь кроме царя этим пользуется? Поняши пишут в Qt Creator’е.

Я раньше пользовался, когда надо было код на C++ править. Он единственный осилил открыть наш жирный CMake проект (вообще-то scons, но я обернул в cmake). Eclipse валился с ООМ, CLion тогда в превью был, а qtcreator что-то тоже глючил. KDevelop норм переварил. Потом я открыл для себя VSCode для не-Java проектов и перелез на него.

Вопрос к пользователям: а вы в таком режиме её и используете, когда в IDE на отображение кода отведено где-то четверть-треть экрана или это для снимка просто так сделано?

Это вполне себе классическая компоновка IDE, многие так и используют. Разве что окно будет развёрнуто на весь экран и кода будет не на четверть-треть а на добрые 3/4 экрана.

Это они MSVS копируют. Там тоже код только через танковую щель.

А царь это кто? Что-то я сто лет уж не слышал это прозвище.

Народ, такой вопрос: а есть какой-то способ автоматической генерации cmake файлов в проекте? Типа, наинклюдил я в заголовках либ, а оно мне автоматом проставило правила для cmake, где искать эти либы? Этакий костяк набить, чтобы потом ручками подправить только то, что нужно.

Вряд ли такое вообще существует в природе. Слишком нетривиальная задача по хедерам выяснять какие библиотеки тебе нужно подключать. Особенно если вспомнить про их наркоманскую версионность без совместимости вниз.

CMakeLists.txt по сути декларативный DSL, хоть и очень сильно наркоманский. По здравому смыслу и интуитивной логике ты сначала вносишь зависимость именно в него, а потом уже используешь в своём проекте.

P.S. А вот у QMake было нечто подобное, но работало оно довольно криво, поэтому редко кто использовал автоматическую генерацию *.pro-файлов на основе девственно чистого дерева исходного кода.

Я пользуюсь

Ты, главное, не зови его и на всякий случай лишний раз не упоминай. А то он и правда придёт и устроит такой срач, что в треде потом ничего не найдёшь, кроме его пердежа. От него информационного мусора даже немного больше чем от byko3y.

hatred

Вбросил, так вбросил.

+1.

На работе проект в CLion всосаться не смог, вся память вытекла (у меня всего 16Гб), а QtC переварил и позволил работать.

+1. Я даже больше скажу: CLion (кажется 2018-4 у меня лицензия была, в общем ещё по-видимому до того как они clang прикрутили) даже на крошечных проектах и на 64GB люто-бешено тормозил, и евойный анализатор кода дико глючил: подчёркивал ошибки там где их нет. Посмотрел я на это… подумал: не, ребята, занимались бы вы уже своей жавой… и решил больше с ним не связываться. Шланг там или не шланг, но ТАКОЕ говно выкатывать, да ещё за бабки (CLion Community Edition не существует) – постыдились бы.

Вау, оно уже в CMake научилось? вот_это_поворот.

Сто лет уже как.

И что немаловажно, работает оно НЕОБЫЧАЙНО шустро. А без джетбрейновских супер-пупер-наворотов я как-нибудь переживу.

С этого места поподробнее. Я, конечно, прямо такими извращениями не занимался, но отлаживать микроконтроллеры в нём вполне отлаживал.

Для примера это: https://habr.com/ru/post/274179/ (статья моя). Дальше, не нашёл, как задать специфичные для тулчейна и целевой платформы параметры для CMake и окружения (конфигурации для CMake задать можно для новых проектов, так что частично вопрос решает)

Если честно, до сих пор не осилил простой сценарий:

1. кросс-сборка на локальной машине
2. деплоймент на удалённую Linux машину с AArch64
3. запуск бинарника там.

С первым пунктом вышло легко, с остальными заминка. Точнее, ручками и пункт два через «Before launch» сделать можно (или плагин какой поискать), но для QtC для базового сценария я даже в настройки деплоймента не иду, базовый набор из коробки работает:

1. Install into temporary host directory
2. Check for free disk space
3. Kill current application instance
4. Deploy files via rsync

Примерный вид на проекте:

• https://i.imgur.com/XVCJ6CO.png (пункты можно выключать, без удаления, устройство для деплоймента тоже можно быстро поменять)

При этом практически для всех полей ввода макроподстановки есть параметров проекта, всякие build/src dir, target, имён бинарников, текущего ssh хоста, порта и т.п.

А вот фича с удалённым тулчейном и сборкой выглядит потрясающе. Правда, частично, на QtC его средствами я тоже реализовал: сборка модуля ядра и его загрузка. Помогает не увести в панику локальную машину кривыми ручками. Но с сообщениями об ошибках да, жвах, нужно как-то маппинг путей делать или скриптами обмазываться, хотя Custom output parsers уже завезли, можно потыкать.

Вау, оно уже в CMake научилось?

Не уловил причины иронии. Я просто про визуализацию настроек:

• https://i.imgur.com/hp4VUkN.png

(что такое и для чего Initial CMake parameters не спрашивай, добавили недавно, формируется из настроек тулчейна, для чего - хз).

Интересно, с чем это связано.

Моё мнение:

1. Удобной организацией тулчейнов в IDE, комбинацией компиляторов, параметров окружения для сборки и запуска, параметров для cmake/qbs/meson (да, его уже тоже завезли, правда в experimental) - один раз настроил и при открытии проекта под платформу выбираешь тулчейн (в терминологии QtC - Kit)
2. Удобным плагином Baremetal. Правда, временами, его ломают. Но, если это мешает мне - я репорчу или коммичу изменения, если раньше никто не успел.
3. Возможностью практически во всех полях ввода использовать плейсхолдеры среды, что добавляет гибкости в организации сложного деплоймента с элементами универсальности.
4. Generic Project Manager - хоть как-то, но загрузить код с любой системой сборки/конфигурирования. Но я стараюсь оборачивать в CMake, если предстоит работать долго и обстоятельно.
5. Наличие исходников и не бесконечного времени на сборку (если что сильно мешает и есть желание).

Недочёты есть, но они худо-бедно обходятся макроподстановками, гибким деплойментом, external tools (сейчас ещё и custom output parsers).

Существенным минусом для меня стало то, что QtC пасует при построении кодовой модели для xTensa и Microblaze: их не поддерживает clang, пришлось ваять костылик, который более-менее универсально работает. Собственно этим я проблему для себя закрыл, в стоковом QtC она остаётся.

Царь от неё был в восторге :D

Ээ? Ху из ит?

Мне и стоковая схема подсветки синтаксиса в Qt Creator сильно цветастой видится.

Тоже дело вкуса. Есть схемы, из коробки, которые достаточно строгие. У меня вообще схема по мотивам BC++, но цветастей :-D

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

Ээ? Ху из ит?

Шизоид :) Регулярно тут устраивал помойку с темах C/C++/Rust. Бложик пациента:

https://tsar1997.blogspot.com

CLion (кажется 2018-4 у меня лицензия была, в общем ещё по-видимому до того как они clang прикрутили) даже на крошечных проектах и на 64GB люто-бешено тормозил, и евойный анализатор кода дико глючил: подчёркивал ошибки там где их нет. Посмотрел я на это… подумал: не, ребята, занимались бы вы уже своей жавой… и решил больше с ним не связываться. Шланг там или не шланг, но ТАКОЕ говно выкатывать, да ещё за бабки (CLion Community Edition не существует) – постыдились бы.

Да, я тоже малость прифигел, когда CLion на:

#include <iostream>

int main(int argc, char *argv[]) {
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

Сожрал 6 GB RAM и полез в swap.

го уже добавили?

Вернулся на него, как они пофиксили ряд неприятных багов. А так перепробовал наверно всё что было доступно, в т.ч. и QtCreator, который не зашёл как-то.

Generic Project Manager - хоть как-то, но загрузить код с любой системой сборки/конфигурирования. Но я стараюсь оборачивать в CMake, если предстоит работать долго и обстоятельно.

Я вот запамятовал, он просто make вызывает или там можно вызов любой сборочной утилиты проставить, типа Gradle или Premake. Отличный плагин для исследования всякого древнего кода, единственное, что меня раздражает – громоздкость проектных файлов.

Все вот эти *.includes, *.creator, *.files можно было бы в один компактный формат завернуть вместо множества мелких.

Кто-то мне заливал что эклипс для крестов реактивен, leave кажется

Нет, вроде не он, не помню

На фоне IDEA-based он действительно работает побыстрее.

Нет, вроде не он, не помню

С вероятностью в 94% это был tailgunner.

Точно не я. Я на крестах если и «пишу», то это десяток строк в виме.

Оно же жирное, кривое и неповоротливое

Алё, QtC - самое лёгкое IDE.

Фича семантической раскрасски даже к виму прикручиваема уже. А про лёву - я не понял, он тоже кривой, жирный и неповоротливый но при этом полезный? Я QtC года 3 не трогал, неужели он успел скатиться, вроде когда последний раз тыкал оба два - кутэкреатор давал жару СиЛьву. Вообще по архитектуре лёва вроде тоже плетётся позади, в криэйторе уже lsp попиливают, а лёва всё ещё сам с libclang упражняется.

Там тулчейны по щелчку пальца добавляются. У меня штук 20 как-то было наконфигурянно на одном из проектов, хоть я и далёк от embedded. Прям под любую перделку, начиная от санитайзинга кончая разными версиями abi для вылавливания багов изысканного использования libc в зависимостях.

Ну и чуть менее чем божественная удалённая отладка. Лучше только голый gdb.

Что ещё за царь-батюшка?

Я и сказал, что не жирнее. Ты понимаешь, да, что !(a > b) это (a <= b)?

В отличие от поделок на жаве, Qt Creator у меня прекрасно жил на гигабайте памяти и двух недоядер интела. Ровно и сейчас прекрасно живет на 16-ти гигабайтах, где не CLion, но схожий по кодовой базе Android Studio развернуться уже не может.

И про бесполезность ты слишком загнул. У него неплохой интерфейс к GDB, какой-никакой анализ кода есть и без необходимости установки Clang Code Model.

Эх, не спрашивай даже.

но схожий по кодовой базе Android Studio развернуться уже не может.

Кстати, туда хоть подсветку синтаксиса CMake-файлов завезли? Когда я последний раз тыкал его и NDK, её не было.

R!

Имхо гораздо юзабельнее creator’а

CMake

Не того человека спрашиваешь.

есть же vim, зачем ещё какие-то DE пилят, время тратят...

ЖОр памяти починили или оно также по 1гб на hello world тратит?

вызов любой сборочной утилиты проставить

Это. Хотя, чисто веселья ради, ты это можешь и в qmake/cmake проектах сделать: указать какой скрипт или команда будет вызвана на этапе сборки и/или указать несколько в виде шагов последовательных:

• https://i.imgur.com/HJp4Oif.png - Generic
• https://i.imgur.com/vUmJLjT.png - CMake

громоздкость проектных файлов.

Это да. Но я другого выхода не вижу, что бы хоть как-то модель кода в адекватное состояние привести, в ситуации когда ну вот вообще неоткуда взять информацию. Хотя, у них же там сейчас и CompilationDatabaseProjectManager есть, так что, если какими-то средствами получилось при сборке сгенерить эту самую базу, то для целей исследования (для разработки, добавления, удаления файлов - так себе, имхо) вполне можно использовать как замену Generic Project Manager.