BLOG-PROG
Добавлен prog,
опубликован
В продолжение к Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
В связи с запланированным обновлением Fly Data Processor, возникла необходимость обновить и сборщик карты, чтобы было кому автоматически запускать Fly Data Processor.
А чтобы обновить сборщик карты не рискуя нарваться на еще одну полную его переделку - полезно сперва определиться со спецификацией. О чем, собственно, этот пост.
Основные требования:
- Сборщик должен быть модульным - в него должно быть возможно встроить любую утилиту, у которой есть консольный режим, при условии вменяемого поведения подключаемой утилиты
- Сборщик должен легко подключаться к любой среде разработки, в которой есть возможность вызывать внешние файлы и передавать им параметры
- Поведение сборщика должно полностью управляться из конфигурационного файла, а передаваемые извне параметры могут только указать на конфигурационный файл и выбрать один из предопределенных конфигурационным файлом режимов работы
Принятые решения:
- Использовать Lua в составе сборщика.
- Заменить конфигурационные файлы Lua файлами, которые могут содержать как конфиги, так и логику сборки.
- Сборщик будет состоять из нескольких частей - управляющее приложение запиленное на C++, конфиги и билд-скрипты на Lua, внешние модули с Lua обертками, плагины для интеграции с IDE.
- В стандартную поставку будут входить встроенные в сборщик "стандартные" модули, Lua обертки для них, плагин для интеграции с vs-code, пресет пустого проекта готовый к работе, внешний запаковщик карты и обертка к нему.
- Любой модуль или обертку будет возможно переопределить или заменить своей реализацией, как на уровне всего сборщика, так и на уровне отдельного проекта.
- Сборщик будет исправно работать независимо от того, установлен ли он отдельно или внутрь папки проекта. Однако при установке внутрь папки проекта сборщик будет автоматически переключаться в режим работы с конкретным проектом, соответственно, при таком режиме установки не будет разделения на глобальные и локальные модули.
Чек-лист на первый релиз
- Подключение и выполнение Lua файлов. done
- Архитектура подключения модулей и выполнения билд-скриптов.
- Внутренний псевдо-модуль "Config", предназначенный для стандартизации работы с конфигами.
- Внутренний модуль "Log", позволяющий добавлять кастомные записи в лог.
- Внутренний модуль "Code", выполняющий поиск, парсинг, сборку и модификацию кода карты.
- Внешний модуль "Pack", выполняющий упаковку карты.
- Внешний модуль "Data" - обертка для подключения Fly Data Processor.
- Тестовый проект карты, в котором есть билд-скрипт, собирающий карту в двух режимах, "разработка" и "релиз", используя все модули.
- Плагин к vs-code, умеющий запускать редактор, сборщик карты в одном из двух режимов и отправлять карту на тестирование.
Чек-лист поведения сборщика
- При запуске без параметров сборщик пытается определить запущен ли он в режиме проекта или в режиме утилиты. Если сборщик запущен в режиме утилиты, то выводится справка об использовании сборщика. Если сборщик запущен в режиме проекта, он находит стандартный билд-скрипт проекта и выполняет стандартный процесс сборки для этого проекта. Если стандартный билд-скрипт не найден, выводится предупреждение и справка об использовании.
- При запуске с одним параметром сборщик ожидает получить путь к папке проекта либо к билд-скрипту. Если путь ведет к папке, то сборщик пытается найти там стандартный билд-скрипт проекта и выполнить стандартный процесс сборки для этого проекта. Если стандартный билд-скрипт не найден, выводится предупреждение и справка об использовании. Если путь ведет к билд-скрипту, то сборщик пытается выполнить этот билд-скрипт в стандартном режиме.
- При запуске с двумя параметрами сборщик ожидает получить путь первым параметром и режим работы вторым. Порядок действий аналогичен запуску с одним параметром, с тем отличием что вместо стандартного режима используется режим выполнения определяемый вторым параметром.
- Для хранения настроек сборщика используется файл config.lua, находящийся в одной папке с исполняемым файлом сборщика, независимо от того, в каком режиме используется сборщик. При отсутствии этого файла, сборщиком производится попытка по косвенным признакам определить ожидаемый режим работы, после чего генерируется config.lua со стандартными настройками.
- При определении режима работы, сборщик ищет файл project.json или project.lua на одну директорию выше своего текущего расположения на диске. Если такой файл найден, то выбирается режим работы в проекте.
- Стандартные настройки подразумевают хранение исходников в папке src внутри папки проекта.
- Стандартные настройки подразумевают хранение всего связаного со сборщиком в папке builder внутри папки проекта. При автоматической генерации конфига в режиме проекта, реальный путь к исполняемому файлу сборщика используется для установки этого параметра.
- Стандартные настройки подразумевают хранение временных файлов возникающих при работе сборщика в папке .build внутри папки проекта.
- При выполнении билд-скриптов сборщик ищет обертки к необходимым модулям, подключает их и затем выполняет сборку.
- При подключении модулей приоритет отдается локальным модулям проекта и только при отсутствии там соответствующего модуля, используется стандартный модуль находящийся в месте установки сборщика. Если сборщик работает в режиме проекта, то считается что у него нет стандартных модулей, только локальные.
- Если модуль не найден ни локально ни в в месте установки сборщика, выводится сообщение об ошибке, после чего сборка прерывается.
Совместимость
World Editor
Совместимость с WE в первой релизной версии планируется на уровне предыдущей версии компилятора - WE и среда разработки для кода могут работать параллельно, сборка и запуск тестирования карты выполняется из среды разработки. В случае необходимости внести в карту изменения, которые должен увидеть WE, будет необходимо закрыть WE, выполнить изменения, открыть WE заново.
Создание карты, содержащей код, таким образом чтобы карту можно было сохранить в WE с сохранением функциональности не входит в задачи сборщика - эта задача должна решаться внешним модулем, подключенным в скрипт сборки. Однако, если будет готовая утилита и Lua обертка к ней, то этот функционал может быть включен в набор стандартных внешних модулей, поставляемых вместе со сборщиком.
WLPM
Поскольку в сборщик изначально не закладывается функционала менеджера пакетов, поддержка WLPM может органично закрыть эту дыру в функционале. Но подробности интеграции еще предстоит обсудить с ScorpioT1000.
"дешёвый" сборщик от NazarPunk
https://xgm.guru/p/wc3/lua-concat-lua
https://xgm.guru/p/wc3/lua-download
https://xgm.guru/p/wc3/lua-read-wct
https://xgm.guru/p/wc3/lua-download
https://xgm.guru/p/wc3/lua-read-wct
Написанные на Lua модули могут быть подключены к сборщику и использованы после минимальной модификации. Однако возникает вопрос подключения сборщика к IntelliJ IDEA.
добавление сборщика к существующему проекту
- сборщик рассчитан на работу с картой в формате папки. Для работы в формате архива понадобится подключение дополнительных утилит умеющих распаковывать карту.
- сборщик ожидает увидеть определенную структуру папок внутри проекта, но до определенной степени это поддается настройки в конфигах.
- сборщик ожидает увидеть файл project.json или project.lua в корне проекта. Имя этого файла может быть изменено в конфиге. Предназначение этого файла - указвать сборщику где находится корень проекта, на случай отсутствия конфигурации, а также хранить метаинформацию о проекте, например его название и версию. В стандартной реализации скрипта сборки, эта информация также вшивается в код карты.
- для успешной сборки проекта сборщику необходим билд-скрипт - скрипт на Lua, указывающий сборщику в каком порядке что делать, какие модули вызывать и так далее. В общем случае, должно быть достаточно стандартного скрипта сборки, идущего в составе сборщика, но его может потребоваться редактировать в соответствии с требованиями проекта.
- в зависимости от требований проекта, к сборщику может потребоваться подключить внешние утилиты. Для этого можно либо напрямую указать их вызов в билд-скрипте, либо обернуть их в "модули", тогда в билд-скрипте будут вызываться функции из API модулей, а луа-код внутри модулей уже будет вызывать внешние утилиты.
- в зависимости от используемой среды разработки, может потребоваться установка дополнительного плагина или ручная настройка вызова сборщика из среды разработки. В стандартной поставке планируется только плагин для vs-code и поддержка запуска сборщика в консольном режиме.
Послесловие
Как и в случае с Fly Data Processor, этот пост является манифестом и планом на будущее, а также местом для сбора фидбека, если кому-то найдется что сказать. О прогрессе разработки и/или релизе будет отдельный пост.
Эта версия сборщика является логическим продолжением предыдущей версии и подразумевает повторное использование кода и перенос фич, однако если у вас есть какие-то идеи или пожелания - высказывайте их в комментариях, даже если уже высказывали их в комментариях к предыдущему посту.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован prog