LINUX.ORG.RU
ФорумTalks

KDevelop & CLang

 , ,


0

2

Нашел следующий вброс на похорониксе:

The KDevelop Clang plug-in has been greatly improved and is on its way to replacing the KDE's integrated development environment existing C++ language support with this Clang-based solution.

There's been many KDevelop Clang improvements landing recently and its quality is surpassing KDevelop's own C++ plug-in that has its own C++ parser and other own implementations. Milian Wolff of KDE explained about Clang for KDevelop as «the magic bullet which we waited for, and which did not exist back when KDevelop 4.0 was started initially.»

Using Clang with KDevelop instead of its own in-house C++ language support leads to a great code reduction: ~50k lines of code for its own solution versus ~2600 lines of code for hooking into Clang. The Clang parser is also much faster than KDevelop's own C++ parser with greater parallelism. KDevelop can also more easily support new C++ features seamlessly as they are added to Clang. Whether Qt Creator will follow KDevelop in this Clang route is still being determined.

Подробности: http://milianw.de/blog/katekdevelop-sprint-2014-let-there-be-clang

★★★★★

Так что получается, теперь llvm будет в зависимостях у KDevelop? Пускай они там сдохнут со своей BSD-лицензией.

GreenTea ★★
()

наконец-то
ждем такого же героического поступка для D на ldc.

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

Пускай они там сдохнут со своей BSD-лицензией.

больной на голову?

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

Так что получается, теперь llvm будет в зависимостях у KDevelop? Пускай они там сдохнут со своей BSD-лицензией.

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

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

Пускай они там сдохнут со своей BSD-лицензией.

KDevelop под GPL. БСД совместима с GPL, потому проблем в линковке нету.

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

Проходим мимо, не задерживаемся.

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

Если llvm включат в основную ветку, то никаких опций не будет, потому что без парсера kdevelop нафиг не нужен.

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

2 сразу нафиг не нужны - это лишний гемор (причем существенный) абсолютно без какого-либо смысла. Поддерживать 2 кода (причем старый большой), а также пилить какой-то общий интерфейс для унификации обращения к разным парсерам. А для чего? Для 2.5 мудаков, да еще и гентушников, которым плевать на трату драгоценного времени разработчиков из-за личных фобий лицензий? Крайне удивлюсь, если они такое сделают.

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

Гентушников можно утешить тем, что встроенный парсер KDevelop таки кое-что умеет, и полная замена его на clang займёт лет 5. Собственно поэтому clang ещё не включён в QtCreator, и даже в версии QtCreator 3.1 будет выключен по дефолту.

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

и полная замена его на clang займёт лет 5

Что-то данная новость это не подтверждает.

The plugin already supports:

  • parsing of full projects, supporting all C++ features that clang supports
  • semantic highlighting
  • code browsing
  • basic code completion, including macros
  • embedding of clang diagnostics, even supporting navigation between nested diagnostics

What’s currently missing:

  • assistants: rename, add type, synchronize signature, …
  • refactoring: move to source, rename, …
  • more advanced code completion: implement function, override virtual function, …
  • context-browsing for macros
  • switches for plain C, Objective-C support

Отсутствуют как раз мелочи.

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

Отсутствуют как раз мелочи.

Это если не знать о вещах, которые под капотом.

  • Есть пачка багов в автодополнении, исправление которых требует патчей к clang
  • Есть пачка багов в диагностике и подсветке, исправление которых опять же требует патчей к clang
  • Флаги компилятора и даже язык пока не ловятся вообще, ни Objective-C, ни Pure-C не поддерживаются, а отсутствие какого-нибудь флага запросто может выдать критические ошибки, из-за которых clang прекратит парсинг
  • Clang, может быть, и быстрее встроенной модели KDevelop, но в QtCreator без предкомпилированных заголовков время парсинга файла (а значит, и время автодополнения кода после написания точки) разнилось от 1 до 5 секунд
  • Чтобы гарантировать наличие предкомпилированных заголовков во всех проектов, нужно менять взгляды других программистов и код тех проектов, плюс надо определить наличе PCH в плагине для системы сборки. Вот это-то и займёт лет 5.
quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

надо определить наличе PCH в плагине для системы сборки

И давно это проблема? CMake парсер есть и может и не такое ловить.

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