-
Notifications
You must be signed in to change notification settings - Fork 0
Current state of generator (RU)
На данный момент можно выделить 4 основные сущности в генераторе проектов:
- Скрипты JS - выполняются один за другим с учетом зависимостей
- Контекст выполнения - структура, передаваемая в каждый скрипт
- Конфигурации JSON - несколько файлов JSON, собираемые в один по определенным правилам
- Модули - подпроекты, содержащие скрипты, исходники и конфигурации
Ниже я расскажу какую роль играет каждая из сущностей.
Скрипты - это костяк генератора. Весь процесс работы генератора - это выполнение скриптов один за другим. Любопытно, что скрипты выполняют большую часть работы. Наверное, это похоже на плагины в Gradle. Точкой входа для скриптов является утилита flappy, которая по задумке находится в глобальной области видимости и может быть вызвана из консоли в любом месте, аналогично гит. Опять же, аналогично гиту, команда flappy понимает, в каком проекте она находится и определяет его корневой каталог. Единственный аргумент, который ожидает flappy - это имя скрипта для запуска. Если имя скрипта передано как аргумент, flappy ищет его в списке каталогов (о списке ниже) и находит функцию run, если такая была экспортирована из скрипта. Однако, сразу заданный скрипт не запускается, сначала утилита flappy опрашивает все остальные скрипты в области видимости и находит те, которые желают выполниться перед заданным скриптом и так рекурсивно. В результате этого процесса, мы имеем последовательность скриптов для выполнения. Последовательность выполнения задается в самих скриптах, в массивах before и after.
Пример скрипта:
module.exports.run = function (context) {
};
module.exports.before = ["gen"];
Данный скрипт будет автоматически найдет и запущен перед скриптом gen. Это позволяет выполнять препроцессинг, генерацию исходных файлов, поиск SDK и многое другое.
Не все скрипты обязательно можно вызвать при помощи flappy, некоторые скрипты содержат только полезные функции и их нельзя вызвать. Разумеется, пользователь может легко добавить свой скрипт в проект для выполнения предварительной конфигурации, сбора информации о системе, генерации исходников и прочего.
Наборы скриптов распространяются внутри модулей. Если модуль содержит скрипты, то они автоматически попадают в область видимости и могут модифицировать конвейер.
Контекст передается в каждый скрипт и содержит в себе конфигурацию, список всех модулей, функции для поиска других скриптов в зоне видимости, корневой каталог, другие полезные вещи. Скрипты могут изменять контекст, затем он движется к другому скрипту. На данный момент это же является недостатком системы. В будущем я планирую ограничить возможности изменения контекста из скриптов, но не все сразу.
Конфигурация, это входные данные для скриптов. Конфигурация, представляющая собой JSON файлы межржится из нескольких файлов последовательно и передается на вход скриптам. Скрипты вправе изменять конфигурацию как им вздумается (да, мне тоже это не нравится и я надеюсь ситуация улучшится в будущем). Такой подход позволяет изменять набор исходников и конфигурацию динамически. Например, производить поиск SDK, как я делаю с SDL2 и Vulkan. Подобный функционал реализуется в CMake, но все же, поиск конфигурации гораздо удобнее реализовать на js, чем на CMake.
При запуске скрипта flappy, можно указать, какие конфигурации использовать для сборки, это полезно для модификации проектов для разных дистрибьютеров, тестирования, отладки и т.д. Это очень напоминает механизм flavor'ов из Gradle, с тем отличием, что каждая такая конфигурация располагается в отдельном файле. Добавление конфигураций производится с помощью аргумента +<имя конфига>. Например flappy gen cmake +debug +test_menu +local_server
Это довольно важный момент. Область видимости определяет то, какие конфигурации будут мержиться и какие скрипты доступны. По умолчанию, в конфигурацию попадают папка flappy_conf из каталога установки и папка ~/.flappy. К ним добавляется папка flappy_conf из каталога проекта. Несложно догадаться, что ~/.flappy используется для настройки локальной конфигурации, там можно задать расположение и версии используемых в системе библиотек и прочее.
Область видимости скриптов определяется аналогичным образом, каталог установки/scripts + ~/.flappy/scripts + каталог проекта/scripts. Однако, кроме этого, в область видимости добавляются скрипты из всех модулей, что позволяет добавлять поведение в проект путем добавления модулей.
По сути, проект FlappyTools сам является модулем и указывает зависимости от других модулей. В плане конфигурации, все модули равноправны, однако различия появляются на этапе исполнения скриптов. Модуль, из каталогов которого была вызвана команда flappy автоматически считается основным и все скрипты будут обрабатывать его как основной проект. Еще раз важный момент: Скрипты выполняются ТОЛЬКО один раз и только для основного проекта, скрипты могут обращаться к модулям они могут опционально, по желанию. Даже скрипты, которые находятся в подпапках модулей выполняются так, как будто они находятся в основном проекте и по желанию могут обращаться к модулю, в котором они физически находятся.