LINUX.ORG.RU

KDevelop 5.1.0

 , , ,


0

7

Разработчики KDevelop анонсировали релиз новой версии кроссплатформенной IDE, предназначенной для работы над проектами на языках программирования C, C++, Python, PHP и JavaScript/QML. Код IDE распространяется под свободной лицензией и использует фреймворки KF 5 и Qt 5. Для тестирования возможностей нового KDevelop был приготовлен специальный AppImage-образ, который можно получить на странице загрузок.

Поддержка LLDB

В рамках мероприятия GSoC 2016 в KDevelop была реализована поддержка высокопроизводительного отладчика нового поколения LLDB, который развивается проектом LLVM. В результате выполненной работы, в IDE появился внутренний фреймворк отладки, который может быть использован как для взаимодействия с GDB, так и с LLDB MI. LLDB-плагин умеет напрямую общаться с драйвером LLDB MI (lldb-mi), что позволяет использовать LLDB в качестве альтернативного backend-отладчика. Кроме того, поддержка нового инструмента будет очень полезна для KDevelop на macOS и MS Windows, когда порт LLDB на эти операционные системы станет достаточно стабильным.

Режим анализа кода

KDevelop версии 5.1.0 получил новый пункт главного меню «Analyze», в котором сосредоточены различные инструменты для исследования исходного кода проектов. Несколько месяцев назад разработчики завершили интеграцию плагина поддержки анализатора cppcheck в репозиторий KDevelop, благодаря чему этот инструмент стал доступен в IDE «из коробки». Плагины для поддержки остальных анализаторов, таких как Valgrind, clang-tidy и krazy2, ещё не стабилизированы, поэтому они пока находятся в своих собственных репозиториях. Со временем ситуация может измениться и эти инструменты в новых версиях KDevelop станут доступны сразу после установки.

Поддержка OpenCL и грядущая поддержка CUDA

Теперь IDE может корректно разбирать и подсвечивать код, написанный на языке программирования OpenCL. Поскольку KDevelop перешёл со своего стокового парсера на тот, что развивается проектом Clang/LLVM, поддержка языка OpenCL досталась ему «в наследство». Изменения исходного кода KDevelop для обеспечения его корректной работы с OpenCL были минимальны. Кроме того, в версии 5.2.0 будет добавлена поддержка работы с файлами CUDA от NVidia.

Улучшенная поддержка языка Python

В KDevelop теперь поддерживается синтаксис и семантика языка Python версии 3.6. Благодаря работе Фрэнсиса Херна были исправлены различные долговременные проблемы в семантическом анализе Python-кода. Решение этих проблем позволило очистить код KDevelop от старых и плохо спроектированных конструкций, что значительно упростило внесение изменений и поддержку. Кроме того, была полностью переписана система проверки Python-кода на соответствие стилю кодирования PEP8, что сделало её быстрее и настраиваемее.

Интеграция Perforce

Благодаря Мортену Даниэльсену Волдену KDevelop 5.1 обзавёлся поддержкой коммерческой системы контроля версий Perforce, для работы с которой необходимо просто установить Perforce на компьютер и обеспечить возможность запуска исполнительного файла p4. Подобным образом организована работа и с другими VCS, например, Git и Bazaar.

Выбор цветовой схемы внутри KDevelop

Теперь можно выбирать цветовую схему из самого KDevelop. Реализацию подобной функциональности очень часто просило большое количество пользователей этой IDE. Если KDevelop запускался в окружении рабочего стола, отличного от KDE Plasma 5, то раньше это составляло определённые трудности, поскольку настройки цветовой схемы были недоступны. Теперь нет никаких препятствий для выбора любимой расцветки IDE.

Поддержка других платформ

Разработчики KDevelop постоянно работают над версией этой IDE для MS Windows и планируют выпустить первую версию KDevelop для macOS в ближайшее время. В релизе под MS Windows фреймворк KF 5 был обновлён до версии 5.32, а инструментарий Clang/LLVM до версии 3.9.1.

>>> Страница загрузки KDevelop

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

★★★★★

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

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

А откуда ему знать, во что должен превратиться код после отработки мета-компилятора?

А с чего ты решил, что после отработки moc-а код во что-то превращается? moc лишь генерирует реализацию нескольких методов, а исходный код он не трогает. Ну и по поводу сигнал-слотов - в большинстве случаев можно просто напрямую связывать методы.

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

Ну родной парсер же знает. Впрочем это больше беда qt, не стоило им вводить мок ой не стоило. Либо обходились бы стандартом и писали слоты через наследование листенеров (java like), либо подождали С++11 прежде чем писать qt, либо выбрали бы язык удачнее. А так вышли костыли.

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

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

А с чего ты решил, что после отработки moc-а код во что-то превращается?

// a.cpp
#include "bar.h"

int foo(const Bar& bar)
{
   bar. // <--
}



Что должен сделать комплитер, без знания содержимого bar.h?

Ну и по поводу сигнал-слотов - в большинстве случаев можно просто напрямую связывать методы.

Вам виднее. Я лишь сделал предположение, что сигнал-слоты в Qt - это что-то зависящее от мета-компилятора.

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

Ну родной парсер же знает.

Вероятно, что у родного парсера для этого сделаны костыли.

Почему разработчики Qt поступили так, тоже понятно. Им нужен был новый C++ сразу, а не после 2011 года.

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

Наверное можно сделать с помощью макросов, которые будут эмулировать сигнал-слоты.

andreyu ★★★★★ ()
Ответ на: комментарий от MuZHiK-2

Зашел на загрузку, там

Mac OS (Preview Versions): No official prebuilt installers available yet, Build KDevelop from source


И каким красноглазым это нужно в таком виде?

Плохо ты луркал

brew tap haraldf/kf5
brew install kdevelop --HEAD
Это если в двух словах, но сборка валится на kwallet, мне пришлось вручную выпилить его из зависимостей.

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

Мультикурсор нужен чтобы говорить «я не копипастер! я СРАЗУ пишу код в нескольких экземплярах, мультикурсорность же».

slonopotamus ()

предназначенной для работы над проектами на языках программирования C, C++, Python, PHP и JavaScript/QML

АааааааааааААААаааААААААаааА!!!! *оргазменный экстаз*

А давно там питон появился??? Моя любимая IDE со времен когда еще прогал на С++, потом перешел на питон, и вощем саблайм все дела, большой проект, хорошей IDE стало нехватать... ВОТ ТАК НОВОСТЬ!!!

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

и как это связано с твоим комментарием? в нем бы появился смысл, если бы в новости было сказано, что имеется версия под макос и разработчики говорят, что все готово и отлично, а при этом заставляют все собирать ручками самим.

а так тебе нормальным языком написали:

Разработчики KDevelop постоянно работают над версией этой IDE для MS Windows и планируют выпустить первую версию KDevelop для macOS в ближайшее время.

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

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

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

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от anonymous

и как это связано с твоим комментарием?

Так, что любой более-менее серьезный софт работает под маком, а тут столько пафоса, а собрать образ не смогли.

MuZHiK-2 ★★★★ ()
Ответ на: комментарий от yurikoles

Этот восхитительный сайт попытался мне вирусов в андроид напихать. Специально эту помойку искал?

Stil ★★★★★ ()

Как там с CMake? Появилось что, что утянуть можно?

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

Впрочем это больше беда qt, не стоило им вводить мок ой не стоило.

стоило. Не от хорошей жизни.

Либо обходились бы стандартом и писали слоты через наследование листенеров (java like)

Ад ещё тот.

либо подождали С++11 прежде чем писать qt, либо выбрали бы язык удачнее

вспомни, когда KDE1 появился. 1998 год. А Qt1, соответственно, ещё раньше - начало 1995. Бум ООП во все поля. А C++ был тогда достандартным неандертальцем. Других популярных вариантов я не особо-то вижу в роли нативной кросс-платформы. Java Swing же, уродство ещё то.

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

Просто вкупе с фичами 2011 стандарта (а плагин вышел из стадии experimental как раз уже после нового стандарта) и продвигаемой Qt5, где рекомендовано использовать новый формат сигнал-слотов, такой хук мало кому нужен. К тому моменту как его впилят, он уже перестанет быть необходимым даже тем, кто сейчас ещё использует SIGNAL(xxx)/SLOT(xxx).

походу шланговый парсер в креаторе ... тормозит прилично

ещё и памяти кушает прилично. Но это... беда шланга. Все реализации парсера поверх шланга тормозные и жрущие. Будь то, хотя бы, плагин для vim или emacs. Ещё он нестабильный и падает очень активно на пользовательских данных, потому его вынесли в отдельный процесс. Из плюсов: если сильно разжирел, можно успешно сделать kill -9 без фатальных последствий для работы: перезапустится и начнёт отъедаться снова. Рекомендую, кстати, закрывать неиспользуемые файлы - чем меньше открыто, тем меньше нагрузка на мозги (в прямом и переносом смысле). А вообще, в рассылке был эпик: просто обновление от 3.8 до 3.8.1 решило пачку проблем в трекере QtC.

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

Ждать по две секунды пока откроется подсказка ещё то удовольствие.

не заметил. Но активно только два проекта на 50 kLOC и ~10 MLOC. Но замедляется, если долго в работе, это да. Выше рекомендации небольшие. И да, не заглядывал во внутрь, но похоже там какое-то подобие инкрементной компиляции реализовано. Сижу на master-версии.

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

Кстати, он ещё перестал понимать умные указатели при навигации :)

struct Foo
{
  void foo() {}
};
...
std::unique_ptr<Foo> foovar;
...
foovar->//автодополнение работает
foovar->foo(); // а вот Ctrl+Click уже не видит символа foo()

всё не дойдут руки или репорт сделать или проголосовать за существующий.

ЗЫ master сборка из git, но тянется давно, до 4.2 вроде появилось ЗЗЫ да, больше, походу, моих сборок в PPA не будет - дистрибутив несколько поменялся :)

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

При том, что QtC можно скачать в виде .run дистрибутива и поставить в домашнюю директорию, даже не понимаю, зачем использовать старьё из дистрибутива. Если бы дистрибуторы ещё пачку сторонних плагинов собирали, ещё бы понятно было. А так... хз.

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

«выбран шланговый потому что плагин загружен».

просто выключите плагин и перезапуститесь. Будет использован встроенный. Любой git pull огромную пачку изменений в поддержке шланга загружает. Пилят.

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

У меня стойкое ощущение, что они ввязались в C++ только потому, что гугл использует их IDE как Android Studio, а NDK таки нужен: более менее серьёзный или сложный проект его уже использует. А раз нужен NDK, то нужно и в C/C++ уметь.

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

Стоковый парсер хоть и врублен по дефолту, он давно уже Deprecated:

в 4.2 же вроде уже как загружен по умолчанию?

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

Если бы дистрибуторы ещё пачку сторонних плагинов собирали, ещё бы понятно было. А так... хз.

Консистенция же. А потом мучаются, потому что по дефолту в том же Debian вообще 3.2.1

У меня стойкое ощущение, что они ввязались в C++ только потому, что гугл использует их IDE как Android Studio, а NDK таки нужен: более менее серьёзный или сложный проект его уже использует. А раз нужен NDK, то нужно и в C/C++ уметь.

При этом поддержка NDK в Android Studio всё ещё не доросла до вменяемой, хотя прошло уже два года. Ещё они пытаются перебросить пользователей с Makefile'ов (Android.mk) на CMake, но поскольку огромный пласт NDK-проектов не горит желанием переходить на CMake, они так и застряли в этом выборе. И хоть они заявляют что-то вроде «поддержку ndk-build мы скоро отключим, переписывайте всё на CMake», на дели никому до этого особого дела нет.

в 4.2 же вроде уже как загружен по умолчанию?

Я точно не знаю, я включил его уже довольно давно. А потом просто обновлялся через пакетный менеджер, и эта настройка сохранялась. Кстати 4.2 прилетел спустя день после официального релиза на сайте (Arch Linux).

EXL ★★★★★ ()

A что на счёт CLion, он ещё сильно сырой?

devorg ()
Ответ на: комментарий от h4tr3d

При том, что QtC можно скачать в виде .run дистрибутива и поставить в домашнюю директорию, даже не понимаю, зачем использовать старьё из дистрибутива.

Тот что из run-файла собран со статической культей и выглядит не очень, ЕМНИП с зашитым кутешным стилем fusion. Дистрибутивный же будет использовать дистрибутивную qt - и в кедах выглядеть как родное к примеру. Ну и еще могут быть различия в qbs.

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

A что на счёт CLion, он ещё сильно сырой?

Ну... выше есть упоминание отдельных нюансов. Но из личной практики: рабочий проект + CMake, около 10 MLOC:

  1. Винда+Clion+SSD: проект всасывался минут 15 активно мигая лампочкой активности диска [хинт: возможно побочный эффект от антивируса]
  2. Винда+VirtualBox+Linux+QtC+HDD: проект всасывался примерно за 2 минуты.

Плюс меньше удобностей в конфигурации CMake:

  • переключение между билд-конфигурациями (её нет), например, между Debug/Release
  • задание параметров для билда (как следствие предыдущего пункта) и их управлением

При этом умеет добавлять файлы к таргетам, т.е. разбор CMake там неплох.

И идеи для рефакторинга там конечно лучше. Но сильно палочкой не тыкал.

Ну и чего мне не хватает:

  • возможностей внутрисхемной отладки (автоматический запуск того же OpenOCD).
  • Просто удалённая отладка уже появилась, но, по сути, номинальная.
  • Настройки тулчейнов. Хотя Clion пытается высасывать настройки «динамически» из CMake конфигурации. Пока не определился - что лучше: указывать тулчейном CMake'у какой компилятор использовать (возможности тулчейнов больше) или пытаться вытянуть настройки из самого CMake, а его запускать со своим CMAKE_TOOLCHAIN_FILE (который ещё не так удобно задать: см выше).
  • Открытости кода. Так как мелкие раздражающие баги я в QtC для себя сам могу быстро решить + настроенный Gerrit и как следствие - подача изменений на ревью и интеграцию (ну не люблю я баг-репорты писать :)).

Про иные хоткеи, диалого и подходы в навигации не пишу: дело вкуса и привыкаешь за месяц-другой.

При этом я бывает некоторые фичи, замеченные в Clion накидываю в трекер QtC ;-) Сейчас вот начинает формироваться некоторое подобие выбора контекстов парсера: http://imgur.com/a/XpWcm

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

Тот что из run-файла собран со статической культей и выглядит не очень.

Нужно попробовать, давно в таком виде его не использовал, но проблем с отображением не припомню (хотя, недавно оказалось, что я просто не требовательный в этом плане). Но как вариант для ленивых :) Или искать PPA (в рачиках и так свежий быстро появляется).

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

Тот что из run-файла собран со статической культей и выглядит не очень

Там используются SO-шки, с обычным скриптом запуска и LD_LIBRARY_PATH. Не знаю, где ты статику увидел.

http://esxi.z-lab.me:666/~exl_lab/screens/qtcreator_libs.png

ЕМНИП с зашитым кутешным стилем fusion. Дистрибутивный же будет использовать дистрибутивную qt - и в кедах выглядеть как родное к примеру.

Да, это так. Но нет ничего сложного в том, чтобы сделать

cp /lib64/qt/plugins/kstyle_breeze_config.so ~/qtcreator-4.2.1/lib/Qt/plugins/
cp -R /lib64/qt/plugins/org.kde.kdecoration2/ ~/qtcreator-4.2.1/lib/Qt/plugins/
cp -R /lib64/qt/plugins/styles/ ~/qtcreator-4.2.1/lib/Qt/plugins/

Ну и еще могут быть различия в qbs.

Никаких различий. Разве что в том, что в сборочке с сайта будет последний стабильный qbs, который будет иметь большее количество фич.

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

но проблем с отображением не припомню

Там зашит только Fusion и, вроде, GTK+

Поэтому сборочка с официального сайта Qt выглядит более-менее нативно в GTK+-окружениях (GNOME/Cinnamon/Unity/XFCE/Mate и др.) и инородно в KDE, поскольку стиля Breeze не положили.

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

Поэтому сборочка с официального сайта Qt выглядит более-менее нативно в GTK+-окружениях (GNOME/Cinnamon/Unity/XFCE/Mate и др.) и инородно в KDE, поскольку стиля Breeze не положили.

Если Gtk+, то вполне можно использовать что-то вроде: http://imgur.com/a/tGIZ6. Но что-то не увидел как переключить стиль в QtC. Раньше вроде в настройках выбрать можно было. Через ком-строку - оно понятно, но не удобно.

Я пока два скрина рядом не сделал, даже отличий не увидел :) А не замечал при длительной работе, потому как использовал, в основном, в Gtk+ окружениях.

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

Там используются SO-шки, с обычным скриптом запуска и LD_LIBRARY_PATH. Не знаю, где ты статику увидел.

Просто предположил, раз run-файл без установленного qt запускается.

Да, это так. Но нет ничего сложного в том, чтобы сделать

Отлично, раз так можно. Значит так и сделаю, если захочется какую бету креатора попробовать.

Никаких различий. Разве что в том, что в сборочке с сайта будет последний стабильный qbs, который будет иметь большее количество фич.

Не, тут наоборот претензия к креатору из дистрибутива - у меня никогда не работал дистрибутивный qbs из креатора на Qt-проектах. Только из консоли руками. А вот со скачанным - все работало.

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

Просто предположил, раз run-файл без установленного qt запускается.

В исполняемый run-файл действительно вкомпилен статический Qt, чтобы можно было развернуть Qt Creator на любой системе, где есть XOrg. Но в самой IDE тот статический Qt из установщика не используется совершенно никак.

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

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

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

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

перестал понимать умные указатели

Есть такое. Наверно сделано специально, чтобы народ переходил на кутешные умные указатели. Вот только нету у куте move semantics еще, следовательно массивы умных указателей не работают. Вот и приходится узать stl.

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

Как там с CMake?

Поддержка присутствует.


Появилось что, что утянуть можно?

В смысле?

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

Мультикурсор нужен чтобы говорить «я не копипастер! я СРАЗУ пишу код в нескольких экземплярах, мультикурсорность же».

Аргумент принят :)

andreyu ★★★★★ ()
Последнее исправление: andreyu (всего исправлений: 1)

а в нем уже появился отладчик для php как в netbeans? а то помнится раньше чего-то было но это ставилось отдельно через танец с бубнами.

wand ()
Ответ на: комментарий от XMs

Поддержка присутствует.

она сильно деградировала по сравнению с 4 линейкой. Смотрел код недавно: столько закомментированного кода я ещё нигде в паблике не видел.

В смысле?

к себе в CMakeProjectManager2 для QtC :-D

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

Да не. Этот косяк регулярно вылазит. Возьми даже объекты в контейнере (std::vector) - та же фигня.

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

она сильно деградировала по сравнению с 4 линейкой

Увы, да.


к себе в CMakeProjectManager2 для QtC

Тут уж не знаю

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

В любом случае, не думаю, что это специально. Так же любой RAII класс поломать можно. Да и аналога unique_ptr у них попросту нет ;-) При этом они сами его использую в QtC.

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

A что на счёт CLion, он ещё сильно сырой?

он стоит как китайский программист на фуллтайм

clover ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.