Каков наилучший подход к пошаговой компиляции при построении DSL с использованием Eclipse? - PullRequest
Новая
       29

Каков наилучший подход к пошаговой компиляции при построении DSL с использованием Eclipse?

6 голосов
/ 22 апреля 2011

Как указано в документации по Eclipse, у меня есть org.eclipse.core.resources.IncrementalProjectBuilder, который компилирует каждый исходный файл, и отдельно у меня также есть org.eclipse.ui.editors.text.TextEditor, который может редактировать каждый исходный файл.Каждый исходный файл компилируется в свой собственный модуль компиляции, но он может ссылаться на типы из других (уже скомпилированных) исходных файлов.

Две задачи, для которых это важно:

  1. Компиляция(чтобы убедиться, что используемые нами типы действительно существуют)
  2. Автозаполнение (для поиска типа, чтобы мы могли видеть, какие свойства / методы присутствуют в нем)

Для выполненияэто, я хочу сохранить представление всех скомпилированных типов в памяти (ниже называемый моим "хранилищем типов").

Мой вопрос состоит из двух частей:

  1. Задача одна, указанная выше, выполняется редактором, а задача 2 - редактором.Чтобы они оба имели доступ к этому хранилищу типов, должен ли я создать статическое хранилище где-нибудь, к чему у них обоих может быть доступ, или Eclipse предоставляет более удобный способ решения этой проблемы?Обратите внимание, что именно затмение, а не я, создает экземпляры сборщиков и редакторов, когда они необходимы.

  2. При открытии затмения я не хочу перестраивать весь проект просто такЯ могу заново заполнить мой тип магазина.Мое лучшее решение на данный момент - сохранить эти данные где-нибудь, а затем снова заполнить мой магазин этим (возможно, при открытии проекта).Так ли это делают другие инкрементные компиляторы?Я полагаю, что подход Java заключается в использовании специального синтаксического анализатора, который эффективно извлекает эти данные из файлов классов.Это мой первый DSL.

1 Ответ

2 голосов
/ 24 апреля 2011

Это интересный вопрос, который не имеет простого решения. Я постараюсь описать потенциальное решение, а также немного подробнее описать, как JDT выполняет инкрементную компиляцию.

Сначала немного о JDT:

Да, JDT читает файлы классов для некоторой информации, но только для библиотек, у которых нет исходного кода. И эта информация действительно используется только для помощи в редактировании (помощник по контенту, навигация и т. Д.).

JDT вычисляет инкрементную компиляцию, отслеживая зависимости между модулями компиляции по мере их компиляции. Эта информация о состоянии хранится на диске, извлекается и обновляется после каждой компиляции.

В качестве более полного примера предположим, что после полной сборки JDT определяет, что A.java зависит от B.java, который зависит от C.java.

Если в C.java есть структурное изменение (структурное изменение - это изменение, которое может повлиять на внешние файлы (например, добавление / удаление не закрытого поля или метода)), то B. Java будет перекомпилирован. A.java не будет перекомпилирован, поскольку в B.java не было структурных изменений.

После этого небольшого разъяснения о том, как работает JDT, вот несколько возможных ответов на ваши вопросы:

  1. Да. Это должно быть сделано через статически доступные глобальные объекты. JDT делает это через объекты JavaCore и JavaModelManager. Если вы не хотите использовать глобальные синглтоны, вы можете получить доступ к вашему хранилищу типов, доступному через экземпляр активатора Bundle вашего плагина. Проект e4 допускает внедрение зависимостей, что, вероятно, даже лучше (но на самом деле не является частью основных API Eclipse).
  2. Я думаю, что сохранение информации в файловой системе - ваш лучший выбор. Единственный реальный способ определения инкрементных зависимостей компиляции - это полная сборка, поэтому вам нужно где-то сохранить информацию. Опять же, вот как это делает JDT. Информация хранится в каталоге .metadata ваших рабочих пространств где-то в плагине org.eclipse.core.resources. Вы можете взглянуть на класс org.eclipse.jdt.internal.core.builder.State, чтобы увидеть реализацию.

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

...