Сборка пакетов с mb2

• Инструмент mb2
• Особенности работы mb2
• Запуск mb2 для проектов для ОС Аврора
• Возможности mb2
• Дополнительные аргументы mb2

Инструмент mb2

После того, как пользователь установил Аврора SDK и настроил эмулятор, он может создавать пакеты локально для целевой архитектуры, используя сборочный скрипт mb2, вызываемый из Аврора SDK. Этот скрипт представляет собой оболочку для ScratchBox2 (sb2) и rpmbuild, которая упрощает сборку пакетов из исходных репозиториев с учётом файла спецификации RPM (.spec).

mb2 находится в /usr/bin/mb2 в SDK chroot.

Особенности работы mb2

mb2 выполняет подмножество команд сборки в контексте rpmbuild. Обычно он вызывается из QtCreator для выполнения фаз сборки проекта qmake/make.

Следует обратить внимание, что любые другие шаги сборки в файле .spec также будут выполняться. Инструмент будет искать .spec-файл в текущем каталоге rpm/. Если таких файлов несколько, можно указать целевой в параметре mb2 -s.

CWD используется в качестве базового каталога для installroot/ и RPMS/ для обеспечения теневых сборок.

mb2 осведомлен о spectacle и обновит spec-файл, если найден более новый yaml-файл.

Если существует файл с расширением .changes, имя которого совпадает с именем spec-файла, эффект будет таким же, как наличие раздела %changelog в spec-файле. Если вместо этого будет найден файл с расширением .changes.run, этот файл будет выполнен, а его вывод будет обработан как фактический журнал изменений.

Запуск mb2 для проектов для ОС Аврора

Сценарий mb2 для сборки пакета вызывается следующим образом:

mb2 -s <path/to/rpm.spec> -t <SDK_target> build

Следует обратить внимание, если в проекте в подкаталоге rpm/ содержится только один файл .spec, параметр -s <path/to/rpm.spec> становится необязательным.

Например, следующая команда может быть использована для сборки большинства проектов. Она занесёт результаты в формат .rpm для дальнейшей установки. Для выполнения этой команды необходимо запустить её из Platform SDK chroot в каталоге проекта, используя таргет с архитектурой i486 или x86_64 для версии 5.0.0 и выше:

mb2 -t <таргет_с_архитектурой i486> build

Выходные файлы .rpm будут находиться в подкаталоге RPMS/ проекта. В качестве альтернативы можно использовать опцию -o|--outputdir, чтобы позволить mb2 хранить файлы .rpm в общем каталоге для упрощения развёртывания.

mb2 -t AuroraOS-i486 -o ~/RPMS build

Эти файлы .rpm могут быть установлены на устройство или эмулятор в зависимости от того, под какую архитектуру они были собраны.

Возможности mb2

mb2 также можно использовать следующими способами:

• mb2 qmake [<args>] запускает qmake в  фазе сборки. Следует обратить внимание, что он при этом проверяет актуальность целевых зависимостей сборки.
• mb2 make [<args>] запускает make в фазе сборки;
• mb2 deploy –zypper|–pkcon|–rsync|–sdk выполняет установку собранных ранее в директории RPMS/ пакетов на целевом устройстве;
• mb2 run|ssh [<args>] запускает команду (на устройстве, если задано –device); предназначен для запуска GDB и GDB-сервера;
• mb2 install [<args>] запускает фазу установки для установки в  $buildroot;
• mb2 installdeps [<args>] обновляет кэш zypper для данной цели и при необходимости устанавливает зависимости сборки;
• mb2 rpm [<args>] запускает фазы установки и создания rpm-пакета;
• mb2 apply [-R] применяет все патчи, определённые в спецификации из каталога rpm.

Дополнительные аргументы mb2

Помимо аргументов -s и -t, которые были описаны ранее, у mb2 имеются следующие аргументы:

• -i  |  –increment — увеличить номер релиза в файле спецификации;
• -d  |  –device — указать устройство, например:

mb2 -t <таргет_с_архитектурой_i486> build -d <путь_к_устройству>

• -p  |  –projectdir — использовать при запуске теневой сборки или развертывания из другого каталога;
• -f  |  –shared-folder — директория, в которой Аврора IDE использует общие файлы devices.xml и ssh. Эта опция полезна, если опция развертывания используется вне виртуальной машины.
• -x[=<tag>] |  –fix-version[=<tag>] — эта опция подразумевается при использовании внутри рабочего дерева Git (можно использовать -X для переопределения). В SDK это подразумевается только в том случае, если версия, записанная в файле спецификации, имеет значение 0.  Можно использовать последний тег из текущей ветки git в качестве версии пакета или заданного <tag>. Если текущие HEAD, индекс или рабочее дерево отличаются от дерева, обозначенного тегом, к версии пакета будет добавлен суффикс, составленный из имени текущей ветви, отметки времени и коммита SHA1. Если git-состояние не является чистым, будет создана структура git-stash и её SHA1 будет использоваться вместо HEAD.
• -X  |  –no-fix-version — переопределить параметр –fix-version;
• -n  |  –no-deps — не  обновлять целевые зависимости;
• -c[=<args>] |  –git-change-log[=<args>] —  включить журнал изменений, сгенерированный из истории Git с помощью команды git-change-log, передавая любые <args>. Эта опция не предназначена для обычного использования — нужно создать файл сценария, с таким же именем, как у .spec-файла, но с расширением .changes.run, чтобы дать для mb2 команду сгенерировать журнал изменений с помощью git-change-log <args>.
• -m  |  –submodule — использовать указанный каталог в качестве подмодуля при применении патчей.