LINUX.ORG.RU

KDevelop 5.6

 , ,


1

3

Команда разработчиков KDevelop выпустила релиз 5.6 свободной программной интегрированной средой разработки, созданной в рамках проекта KDE. KDevelop обеспечивает поддержку различных языков (таких, как C/C++, Python, PHP, Ruby, и д.р.) с помощью плагинов.

Этот релиз является результатом полугода работы, сосредоточенной в основном на стабильности и производительности. Многие существующие функции получили улучшения и есть одно очень заметное дополнение: отображение встроенных заметок о проблемах в строках исходного кода. Эта функция покажет краткое описание обнаруженной проблемы в строке, содержащей ее. В цвете и с соответствующим значком, в зависимости от серьезности проблемы. По умолчанию строчные заметки будут показываться в строках, содержащих предупреждения и ошибки, но вы можете изменить их так, чтобы они были видны или и для подсказок, или только для ошибок. Вы можете также полностью ее отключить.

Также в этой версии была улучшена поддержка проектов CMake, языков C++ и Python и исправлено множество мелких ошибок.

>>> Подробности

★★

Проверено: alpha ()

Ответ на: комментарий от EXL

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

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

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

hatred ()
Ответ на: комментарий от EXL

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

hatred ()

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

paramon ()
Ответ на: комментарий от hatred

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

всего 16Гб

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

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

EXL ★★★★★ ()
Ответ на: комментарий от hatred

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

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

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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

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

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

cocucka ★★ ()

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

ugoday ★★★★★ ()
Ответ на: комментарий от ugoday

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

EXL ★★★★★ ()

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

ChekPuk ★★★ ()
Ответ на: комментарий от ChekPuk

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

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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от ChekPuk

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

anonymous ()
Ответ на: комментарий от intelfx

@hatred

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

+1.

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

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

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

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

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

dimgel ★★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

Для примера это: 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 научилось?

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

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

hatred ()
Ответ на: комментарий от EXL

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

Моё мнение:

  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

hatred ()
Ответ на: комментарий от dimgel

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

hatred ()
Ответ на: комментарий от dimgel

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.

EXL ★★★★★ ()
Ответ на: комментарий от hatred

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

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

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

EXL ★★★★★ ()
Ответ на: комментарий от intelfx

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

pon4ik ★★★★★ ()
Ответ на: комментарий от EXL

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

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

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

a1batross ★★★★★ ()
Ответ на: комментарий от a1batross

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

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

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

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

hatred ()
Последнее исправление: hatred (всего исправлений: 2)