Руководство разработчика

Репозиторий и зависимости

Перед сборкой клонируйте репозиторий:

git clone https://github.com/fidoboy/moonlight-tizen-ac3.git
cd moonlight-tizen-ac3

В текущем репозитории нет активных подмодулей Git: исходный код необходимых зависимостей хранится непосредственно в репозитории. Достаточно обычного клонирования; выполнять git submodule update --init --recursive не требуется.

Сборка с Docker

Dockerfile репозитория содержит среду сборки и упаковывает виджет Tizen. Из корневой папки репозитория соберите стандартный вариант:

docker build --tag moonlight-tizen-ac3:standard --build-arg BUILD_TYPE=release --build-arg REPO_OWNER=fidoboy --build-arg REPO_NAME=moonlight-tizen-ac3 --build-arg FORCE_GAME_MODE=false .
container_id=$(docker create moonlight-tizen-ac3:standard)
docker cp "$container_id:/home/moonlight/Moonlight.wgt" ./Moonlight.wgt
docker rm "$container_id"

Чтобы собрать пакет ForceGM, повторите сборку с FORCE_GAME_MODE=true и извлеките /home/moonlight/Moonlight-ForceGM.wgt.

Непрерывная интеграция

Workflow Build WGT (CI) проверяет стартовый JavaScript, согласованность переводов и наличие необходимых страниц документации, а затем собирает стандартный пакет и вариант ForceGM. Он запускается при изменениях ветки master и при pull request; его также можно запустить вручную. Артефакты CI — временные тестовые сборки, а не опубликованные версии с тегом.

Публикация публичного релиза

Проект использует собственную последовательность семантических версий, начиная с 1.0.0. Версия виджета Tizen в res/config.xml является основной.

  1. Обновите версию в res/config.xml (например, до 1.0.1 для следующего исправляющего релиза).
  2. Добавьте примечания к релизу в начало CHANGELOG.md.
  3. Создайте коммит с изменениями релиза и слейте его в master.
  4. Откройте Actions → Release WGTs, запустите workflow в master и укажите ту же версию. Workflow проверит версию, не позволит перезаписать существующий публичный релиз, соберёт обе версии WGT и опубликует GitHub Release с тегом vVERSION.

Вместо этого можно отправить Git-тег вроде v1.0.1, предварительно задав соответствующую версию в res/config.xml). Тот же workflow соберёт пакеты и автоматически приложит их к релизу. Стабильные релизы используют обычный семантический тег; предварительные сборки получают суффикс -dev`.

Заметки по разработке аудио

Для Dolby passthrough требуются клиент Tizen и совместимый хост. Предпочтительный вариант — Vibeshine 2.0.3 или новее, где официально поддерживается передача аудио Dolby Digital. Sunshine — необязательная альтернатива: на данный момент поддержка доступна только в экспериментальной ветке и ожидает одобрения для включения в официальный выпуск Sunshine. Dolby passthrough — необязательная функция; она не должна отключать стандартный путь OPUS для хостов, не поддерживающих AC-3/E-AC-3. При тестировании проверяйте фактическое согласование формата и вывод через предусмотренный оптический тракт телевизора, а не только выбранный параметр.

Делайте pull request целевыми, сохраняйте уведомления об авторских правах и лицензиях, документируйте поведение, зависящее от оборудования, и условия тестирования.