LINUX.ORG.RU

Предложен проект создания сервера LLVM/Clang

 ,


0

2

Предложен для реализации проект постоянного кеширующего сервиса Clang Server (clangd) для обслуживания инфраструктуры из множества разнородных, сложных и интерактивных C++ инструментов. В частности этот сервисный слой позволяет обобщить и построить в рамках libclang удобное взаимодействие множества самых разнородных редакторов, интегрированных сред разработки (IDE) и популярных Unix-инструментов разработки. Этот сервис будет реализован строго в рамках Clang/LLVM и будет поддерживать разработку для языков C, C++, Obj-C и Obj-C++.

Сервис будет предоставлять функциональность, которая традиционно присуща для IDE, но при этом задумка заключается в том, чтобы в рамках единой среды дать возможность работать сразу с несколькими разными «плохо интегрированными в систему» редакторами с одновременным обеспечением связности с такими слоями LLVM, как Tooling library, libclang и в потенциале этот сервис будет иметь свою собственную расширяемую через плагины структуру.

Сервис будет построен на базе уже традиционной клиент-серверной архитектуры, с тем единственным исключением, что у клиента будет реализована функциональность для запуска инициализирующей части сервера, если в процессе запуска клиента сервер окажется недоступен, при этом предполагается, что сам сервер будет находиться локально на одной машине с клиентом. Общий дизайн взаимодействия выбран таким, чтобы можно было реализовать socket-подобный обмен сообщениями, ориентированный на стандартный IPC-механизм организации взаимодействия между клиентом и сервером.

Поскольку взаимодействие планируется сделать унифицированным жестко в рамках фреймворка LLVM, коммуникационный протокол будет реализован в форме сериализированных сообщений, закодированных с помощью формата LLVM bitcode. Для всех наборов типов таких сообщений будут определены наборы возможных читателей и писателей подобных bitcode-сообщений. Главная роль сервера — это прием сообщений от клиента, совмещение разных конструкций в рамках Clang, ведение управляющей базы данных, а также результирующие ответы клиентам. Конечная цель — создание максимально упрощенного и эффективного IPC-механизма на базе LLVM, который будет давать следующие конечные преимущества:

  • Обеспечение перезапускаемого, долгоживущего фонового процесса, который управляет кешированием, компиляцией, индексацией и бизнес-логикой.
  • Определение канала и протокола межпроцессорного взаимодействия для создания возможности взаимодействия инструментов разработки друг с другом. В перспективе IPC-слой будет позволять и межмашинное взаимодействие, но это задача не для начальных релизов сервера.
  • Возможность автоматически воспользоваться преимуществами многоядерных процессоров.
  • Поддержка исполнения очень быстрых запросов в интерактивно-интерфейсных режимах, например автодополнение.
  • Предоставление набора базовых инструментов для взаимодействия с сервером через IPC.
  • Предоставление стабильного интерфейса Си API (в виде подмножества вызовов libclang API) для взаимодействия с сервером через IPC.
  • Обеспечение биндинга с Python на основе C API и протокола IPC.
  • Полная совместимость и разделение ресурсов с libclang. Для этого планируется создание двух параллельных интерфейсов для одинаковой базовой функциональности.
  • Эффективная интерфейсная стратегия для всех базовых OpenSource-редакторов. Как минимум должны хорошо поддерживаться Vim и Emacs, также планируется поддержка нескольких редакторов из Windows и Mac.

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

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

★★★★

Проверено: tazhate ()
Последнее исправление: cetjs2 (всего исправлений: 4)

Оо
О чём эта портянка? Просто куча баззворда =\

GAMer ★★★★★
()

Надо было в Development

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

ethercrow
()
Ответ на: комментарий от AVL2

видно apple все таки поставил их в свою любимую позу)

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

Вы хоть исходную серию сообщений читали, это все задумка Google разработчиков, зачем это им они не говорили.

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

А Clang спонсирует эппл. Вот гуглисты и заразились.

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

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

anonymous
()

К сожалению, их амбициозные планы больше похожи на пук. В линуксе даже звуковая библиотека - и тех несколько, каждый использует то, на что хватило ума. Что уж говорить про всякие редакторы с прикрученными сбоку интеллисенсами и подсветкой! Перепиливать ради LLVM тонны говно^W легаси кода никто не будет. Кроме того, всё, что требуется от «модульного конпелятора» - это предоставить АПИ для пары модулей, чтобы редактор мог корректно подсвечивать плюшки и делать подсказки. Зачем для этого целый СЕРВЕР - ума не приложу, наверное ребятам скучно: на дело ума нехватает, а на телегу с наносолнечной тягой - да, время есть! :))

matumba ★★★★★
()

<flame> Google хочет выпустить свой IDE для Go с интегрированным центральным сервисом на их серверах, для проверки всего и вся и одновременно тыринья чужого кода? </flame>

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

насколько я понял: для тырения чужого llvm байткода //fixed

punya ★★
()

имхо идея нравится. не нравится то что оно все будет под bsd

punya ★★
()

Блядь, ЧТО это?!!!

anonymous
()

Я, конечно, ниразу не C (а уж тем более не C++) разработчик, но, кажется, представляю чего они хотят этим добиться. Сидишь, правишь сорцы, изменил пару строчек, и оно сразу же, без получасового ожидания компиляции, готово выплюнуть исполняемый файл, загрузить его в дебагер и заботливо подсветить место в редакторе, на которое ты поставил брякпоинт. Скажете, от пары строчек не будет получасовой перекомпиляции, ибо отдельные объектные файлы? А если это пара строчек в каком-нибудь шаблонном мета-безобразии, на которое плюсы гаразды? Конечно, я могу глубоко заблуждаться, в этом случае поправьте меня (если являетесь квалифицированым C/C++ программистом).

Zveroy
()

Они изобрели CL ?

Reset ★★★★★
()

а чо, если к C/C++/Obj-C приделать хороший REPL, было бы круто.

anonymous
()

Когда я вижу слово «бизнес-логика» я хватаюсь за свой симулякр

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