Джей, компилятор mono C # и изменение грамматики

#c# #.net #mono #jay-parser-generator

#c# #.net #mono #jay-генератор синтаксического анализа

Вопрос:

Я пытаюсь настроить среду сборки для компилятора Mono C # на моем Mac. Цель состоит в том, чтобы расширить грамматику для исследовательского проекта. Я изо всех сил пытаюсь настроить сборку. Я уверен, что ответ очень прост, но пока я не смог найти никакой полезной информации.

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

Файл решения, который я нашел, пока что является моей единственной отправной точкой, включает файл cs-parser.cs, который не существует в исходном коде, который я получил со страниц проекта. Я предполагаю, что этот файл является результатом запуска генератора синтаксического анализа в cs-parser.jay но я не могу найти информацию о том, как настроить это как этап сборки (или, если на то пошло, запустить генератор синтаксического анализатора вручную)

Ссылки на пошаговые руководства по работе с mcs были бы оценены или простой пошаговый

Ответ №1:

Из README.makefiles:

Если в вашей программе есть «встроенные исходные тексты», то есть исходные файлы, созданные из других файлов (скажем, сгенерированные jay), определите переменную с именем BUILT_SOURCES и не перечисляйте источники в $(PROGRAM).sources:

 ========================================
PROGRAM = myprogram.exe
LOCAL_MCS_FLAGS = /r:System.Xml.dll
BUILT_SOURCES = parser.cs
CLEAN_FILES = y.output

include ../build/executable.make

parser.cs: parser.jay
        $(topdir)/jay/jay

lt; > $@
========================================

исполняемый файл.make автоматически удалит файлы $ (BUILT_SOURCES)
при «make clean». Поскольку такая ситуация является обычным явлением, и jay
оставляет после себя y.выходные файлы, вы также можете определить переменную
с именем $(CLEAN_FILES), в которой перечислены дополнительные файлы, подлежащие удалению при вызове ‘make clean’
. (Это в дополнение к вашему исполняемому файлу и встроенным исходным кодам).


Итак, cs-parser.cs создан именно таким образом:

 [mono] ~/custom/MONO/mono/mcs/jay @ make
/usr/bin/make all-local
make[1]: Entering directory `/home/sehe/custom/MONO/mono/mcs/jay'
make[1]: Nothing to be done for `all-local'.
make[1]: Leaving directory `/home/sehe/custom/MONO/mono/mcs/jay'

[mono] ~/custom/MONO/mono/mcs/jay @ cd ../mcs

[mono] ~/custom/MONO/mono/mcs/mcs @ make
/usr/bin/make all-local
make[1]: Entering directory `/home/sehe/custom/MONO/mono/mcs/mcs'
./../jay/jay -cv < ./../jay/skeleton.cs cs-parser.jay > jay-tmp.out amp;amp; mv jay-tmp.out cs-parser.cs
./../jay/jay: 9 shift/reduce conflicts.
 

(уменьшенный вывод)

В результате в cs-parser.cs появилось 10470 строк кода, недоступного для пользователя


Альтернатива, нестандартное мышление:

  1. Просто мысль, нельзя ли использовать конвертер предварительной обработки c # -> c #? Это дает дополнительные преимущества в том, что вы можете заставить его работать с любым инструментом / компилятором C #. Подумайте об использовании #line прагм для сопоставления с исходным источником для получения отладочной информации
  2. Кроме того, существует ряд аспектно-ориентированных разработчиков кода для C # / .NET. Вы могли бы использовать комбинацию 1. и 2. для получения нужной функциональности?

Комментарии:

1. Спасибо за два других предложения. Я думал о перезаписи, но решил отказаться от нее по нескольким причинам, одна из которых — просто упражнение по написанию сложного кода для развлечения 🙂