Справочник по Yocto Project (часть 2)

Глава 5. Структура каталога исходных кодов

Дерево исходных кодов содержит множество компонент и понимание их роли важно для работы с YP. В этой главе описана структура дерева, а также назначение файлов и каталогов. Рекомендации по организации локального дерева исходного кода даны в разделе Locating Yocto Project Source Files [2].

Система сборки OE не поддерживает имена файлов и каталогов с пробелами.

5.1. Компоненты верхнего уровня

В этом разделе описаны компоненты верхнего уровня в дереве исходных кодов.

5.1.1. `bitbake/`

Этот каталог включает копию BitBake для простоты использования. Копия обычно соответствует текущему стабильному выпуску BitBake. Интерпретатор метаданных BitBake считывает YP Metadata и запускает задачи, определенные в них. Отказы обычно связаны с метаданными, а не с BitBake, поэтому большинству пользователей не нужно думать о BitBake.

Можно запускать исполняемый файл bitbake, хранящийся в каталоге bitbake/bin/. Сценарий настройки окружения oe-init-build-env помещает каталоги сценариев и bitbake/bin (в указанном порядке) в переменную окружения PATH.

Информация о BitBake приведена в [4].

5.1.2. `build/`

Этот каталог содержит пользовательские файлы конфигурации и вывод системы сборки OE в ее стандартной конфигурации, где вывод размещается вместе с деревом исходных кодов. Каталог сборки создается при запуске сценария настройки окружения OE (oe-init-build-env).

Можно отделить вывод и конфигурационные файлы от каталога исходных кодов, указав имя каталога при запуске установочного сценария, описанного в параграфе 5.1.9.1 oe-init-build-env.

5.1.3. `documentation/`

Этот каталог содержит исходные файлы документации YP, а также шаблоны и инструменты для создания руководств в формате PDF и HTML. Каждое руководство размещено в своем каталоге, например, файлы для этого документа расположены в каталоге ref-manual/.

5.1.4. `meta/`

В этом каталоге содержатся метаданные OpenEmbedded-Core, задания, базовые классы, конфигурации машин для эмулируемых платформ (qemux86, qemuarm и т. п.).

5.1.5. `meta-poky/`

Конфигурация для эталонного дистрибутива Poky.

5.1.6. `meta-yocto-bsp/`

Этот каталог содержит эталонные пакеты поддержки плат (BSP). Дополнительные сведения о BSP можно найти в [6].

5.1.7. `meta-selftest/`

Каталог с дополнительными заданиями и файлами добавления, используемые при самотестировании OE для контроля процесса сборки. Если самотестирование не требуется, не следует добавлять этот уровень в свой файл bblayers.conf.

5.1.8. `meta-skeleton/`

Каталог с шаблонами заданий для разработки BSP и ядер.

5.1.9. `scripts/`

Этот каталог содержит сценарии, расширяющие функциональность среды YP (например, QEMU). Сценарий oe-init-build-env добавляет этот каталог в переменную окружения PATH. Каталог включает сценарии, помогающие внести свой вклад в развитие YP, например, create-pull-request и send-pull-request.

5.1.9.1 `oe-init-build-env`

Этот сценарий организует среду сборки OE. Сценарий запускается с помощью команды source и меняет значение переменной PATH, а также устанавливает переменные BitBake с учетом текущего каталога. Сценарий установки окружения нужно запускать до использования команд BitBake. Сценарий использует другие сценарии из каталога scripts для выполнения большого объема работ. При запуске сценария создается рабочая среда YP и каталог сборки (Build Directory), который делается рабочим, а также выводится список базовых целей BitBake, как показано ниже.

     $ source oe-init-build-env

     ### Shell environment set up for builds. ###

     You can now run 'bitbake <target>'

     Common targets are:
         core-image-minimal
         core-image-sato
         meta-toolchain
         meta-ide-support

     You can also run generated qemu images with a command like 'runqemu qemux86'

Сценарий получает принятые по умолчанию значения из файла conf-notes.txt в каталоге meta-poky внутри каталога исходных кодов (Source Directory). Если у вас нестандартный дистрибутив, легко изменить этот конфигурационный файл для включения нужных целей для вашего дистрибутива (Creating a Custom Template Configuration Directory [2]).

По умолчанию при работе этого сценария без аргумента Build Directory создается каталог build в текущем рабочем каталоге. Если аргумент Build Directory задан при запуске сценария, система сборки OE создаст указанный каталог. Например, приведенная ниже команда создаст каталог сборки mybuilds вне дерева исходных кодов.

     $ source oe-init-build-env ~/mybuilds

Система сборки OE использует шаблон конфигурационных файлов, который по умолчанию расположен в каталоге meta-poky/conf каталога исходных кодов (см. раздел Creating a Custom Template Configuration Directory [2]).

Система сборки OE не поддерживает имена файлов и каталогов с пробелами. При попытке запуска сценария oe-init-build-env из каталога с пробелами в имени каталога или содержащихся в нем файлов, сценарий будет завершен с ошибкой, указывающей отсутствие каталога. Убедитесь в том, что имя Source Directory не содержит пробелов.

5.1.10. `LICENSE, READMEиREADME.hardware`

Эти файлы являются стандартными для верхнего уровня.

5.2. Каталог сборки `build/`

Система сборки OE создает сборочный каталог при запуске сценария организации среды (oe-init-build-env). Если сценарию не указан каталог сборки, будет создан каталог buildв текущем каталоге. Переменная TOPDIR указывает на каталог сборки.

5.2.1. `build/buildhistory`

Система сборки OE создает этот каталог при включении функции истории сборки. Каталог отслеживает данные сборки по образам, пакетам и SDK (см. раздел Maintaining Build Output Quality [2]).

5.2.2. `build/conf/local.conf`

Этот файл конфигурации содержит все локальные пользовательские настройки для среды сборки. Опции в файле прокомментированы. Любая переменная, задаваемая здесь, переопределяет заданную в другом месте переменную, если та не использует жесткое кодирование (например, = вместо ?=). Такое кодирование применяется для некоторых переменных, но это происходит достаточно редко.

Следует установить в этом файле для переменной MACHINE значения, соответствующее сборке, указать типы пакетов (PACKAGE_CLASSES) и мест, откуда нужно загружать файлы (DL_DIR).

Если файла local.conf нет, система OE создает его по образцу local.conf.sample при настройке окружения (oe-init-build-env). Используемый образец зависит от переменной $TEMPLATECONF, которая по умолчанию указывает meta-poky/conf при сборке из среду разработки YP и meta/conf при сборке из среды OpenEmbedded-Core. Поскольку переменная в сценарии указывает файл local.conf.sample, это позволяет настроить среду сборки из любого уровня, указав в сценарии настройки окружения на верхнем уровне сборки TEMPLATECONF=your_layer/conf. Когда процесс сборки получает файл-образец, используется утилита sed для подстановки значения ${OEROOT} вместо всех ##OEROOT##.

С использованием переменной TEMPLATECONF можно ознакомиться в файле scripts/oe-setup-builddir дерева исходных кодов. Версия файла local.conf.sample для YP находится в каталоге meta-poky/conf.

5.2.3. `build/conf/bblayers.conf`

Этот файл определяет уровни, являющиеся деревьями каталогов, через которые проходит BitBake. Переменная BBLAYERS в этом файле содержит список уровней, которые BitBake пытается найти.

Если файла bblayers.conf нет при запуске сборки, система OE создает его по образцу bblayers.conf.sample при выполнении сценария настройки среды сборки (oe-init-build-env). Используемый образец зависит от переменной $TEMPLATECONF, которая по умолчанию для среды YP содержит значение meta-poky/conf,а дляOpenEmbedded-Core – meta/conf. Поскольку переменная в сценарии указывает файл bblayers.conf.sample file, это позволяет настроить среду сборки из любого уровня, указав в сценарии настройки окружения на верхнем уровне сборки TEMPLATECONF=your_layer/conf. Когда процесс сборки получает файл-образец, используется утилита sed для подстановки значения ${OEROOT} вместо всех ##OEROOT##.

5.2.4. `build/conf/sanity_info`

Этот файл показывает статус проверки работоспособности и создается в процессе сборки.

5.2.5. `build/downloads/`

Этот каталог содержит загруженные архивы исходных кодов. Каталог можно применять для множества сборок или перенести в другое место, указываемое переменной DL_DIR.

5.2.6. `build/sstate-cache/`

Этот каталог содержит файлы общего кэша состояний. Каталог можно применять для множества сборок или перенести в другое место, указываемое переменной SSTATE_DIR.

5.2.7. `build/tmp/`

Система сборки OE создает и использует этот каталог для вывода всех результатов сборки. Каталог указывается переменной TMPDIR. При отсутствии каталога BitBake создает его. При необходимости очистить результаты сборки и начать ее с нуля (все кроме загрузки источников) можно удалить содержимое каталога tmp или сам каталог. В этом случае следует также удалить каталог общего кэша состояний build/sstate-cache.

5.2.8. `build/tmp/buildstats/`

Каталог с данными статистики сборки.

5.2.9. `build/tmp/cache/`

При разборе метаданных (задания и файлы конфигурации) BitBake кэширует результаты в каталоге build/tmp/cache/ для ускорения сборки в будущем. Результаты организованы по машинам. При последующей сборке BitBake проверяет каждое задание (вместе с включенными и добавленными к нему файлами) на предмет изменений. Изменения могут детектироваться по времени редактирования файлов (mtime) или хэш-значениям их содержимого. Если файлы не менялись, используется кэшированный результат, а при наличии изменений файлы анализируются заново.

5.2.10. `build/tmp/deploy/`

В этом каталоге содержаться «конечные результаты» процесса сборки OE. Каталог указывается переменной DEPLOY_DIR.Содержимое каталога описано в разделахImages и Application Development SDK [1].

5.2.11. `build/tmp/deploy/deb/`

В этом каталоге хранятся файлы .deb,созданные при сборке. Пакеты сортируются в хранилища по типу архитектуры.

5.2.12. `build/tmp/deploy/rpm/`

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

5.2.13. `build/tmp/deploy/ipk/`

В этом каталоге хранятся файлы . ipk,созданные при сборке.

5.2.14. `build/tmp/deploy/licenses/`

Этот каталог получает данные о лицензировании пакетов. Например, он может содержать подкаталоги для bash, busybox, glibcи т. п., содержащие файлыCOPYING с описанием лицензирования. Информация о лицензировании приведена в разделе Maintaining Open Source License Compliance During Your Product’s Lifecycle [2]).

5.2.15. `build/tmp/deploy/images/`

Этот каталог получает окончательные образы файловых систем. Если полученный образ нужно записать на устройство, его следует искать здесь. Следует соблюдать осторожность при удалении файлов из этого каталога. Можно безопасно удалять старые образы (например, core-image-*), однако загрузчики ядра (*zImage*, *uImage* и т. п.) и дополняющие их файлы могут быть развернуты в каталоге до создания образов. Поскольку эти файлы не создаются непосредственно из образа, при их удалении они не будут автоматически созданы заново при последующей сборке.

При нечаянном удалении таких файлов их придется принудительно создавать заново. Для этого нужно знать цели, с которыми связаны файлы. Например, можно заново собрать файлы командами

     $ bitbake -c clean virtual/kernel
     $ bitbake virtual/kernel

5.2.16. `build/tmp/deploy/sdk/`

Система сборки OE создает этот каталог для размещения сценариев установки инструментов, выполнение которых обеспечивает инсталляцию файловой системы sysroot, соответствующей целевой платформе. Описание сценариев установки дано в разделе Building an SDK Installer [7].

5.2.17. `build/tmp/sstate-control/`

Система сборки OE использует этот каталог для файлов манифеста общего состояния. Код общего состояния использует эти файлы для записи установленных каждой задачей sstate файлов, чтобы эти файлы можно было удалять при очистке задания или установке новой версии. Система сборки также использует файлы манифестов для обнаружения перекрытий между задачами и выдачи предупреждений.

5.2.18. `build/tmp/sysroots-components/`

Этот каталог содержит компоненты sysroot, которые задача do_prepare_recipe_sysroot указывает (link) или копирует в зависимые от заданий каталоги sysroot каждого задания из DEPENDS. Заполнение этого каталога выполняется через общее состояние, а путь указывается переменной COMPONENTS_DIR. За исключением нескольких экзотических случаев обработка sysroots-components происходит автоматически и заданиям не нужно ссылаться напрямую на build/tmp/sysroots-components.

5.2.19. `build/tmp/sysroots/`

В прежних версиях OE каталог служил для создания глобального общего корня sysroot на уровне машины вместе с естественным sysroot. Начиная с YP 2.7.1, каталоги sysroot размещаются в рабочих каталогах заданий (WORKDIR) и build/tmp/sysroots/ не используется. Однако build/tmp/sysroots/ можно по-прежнему заполнять с помощью команды bitbake build-sysroots и использовать для совместимости. В общем случае использование этого каталога не рекомендуется, следует применять отдельные sysroot для заданий.

5.2.20. `build/tmp/stamps/`

В этом каталоге хранится информация, которую BitBake использует для отслеживания выполняемых задач. Каталог содержит подкаталоги по архитектуре, имени и версии пакета. Например,

     stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do

Хотя файлы в этой структуре не содержат данных, BitBake может отслеживать задачи по именам и временным меткам (см. раздел Stamp Files and the Rerunning of Tasks [1]).

5.2.21. `build/tmp/log/`

Этот каталог содержит журналы сборки, например, вывод задач do_check_pkg и do_distro_check. Запуск сборки не обязательно создает этот каталог.

5.2.22. `build/tmp/work/`

Этот каталог содержит зависимые от архитектуры рабочие каталоги для пакетов, собираемых BitBake. Все задачи выполняются из соответствующих рабочих каталогов. Например, исходные коды для конкретного пакета распаковываются, правятся (patch), настраиваются и компилируются в своем рабочем каталоге. Внутри таких каталогов организация основана на группах пакетов и версиях, для которых будет компилироваться исходный код в соответствии с WORKDIR.

В качестве примера рабочего каталога рассмотрим linux-yocto-kernel-3.0 для машины qemux86. Рабочим каталогом для этого пакета будет tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<…..>, указанный в переменной WORKDIR. В этом каталоге распаковываются исходные коды для linux-qemux86-standard-build, а затем накладываются исправления с помощью Quilt. (см. раздел Using Quilt in Your Workflow [2]). В каталоге linux-qemux86-standard-build создаются стандартные каталоги Quilt linux-3.0/patches и linux-3.0/.pc и могут применяться стандартные команды Quilt.

В WORKDIR создаются и другие каталоги, наиболее важным из которых является WORKDIR/temp/, где хранятся журналы (log-файлы) для каждой задачи в форме log.do_*.pid, а также сценарии BitBake для каждой задачи в форме run.do_*.pid. В каталоге WORKDIR/image/ команда make install размещает выходные файлы, которые затем делятся по пакетам в WORKDIR/packages-split/.

5.2.23. `build/tmp/work/tunearch/recipename/`version`/`

Рабочий каталог задания – ${WORKDIR}. Как описано в параграфе 5.2.19. build/tmp/sysroots/, начиная с выпуска YP 2.7.1, система OE собирает каждое задание в своем каталоге (WORKDIR). Путь к рабочему каталогу создается с использованием архитектуры для данной сборки (например, TUNE_PKGARCH, MACHINE_ARCH
или allarch), имени задания и его версии (например, PE:PV-PR).

В рабочем каталоге каждого задания имеется множество подкаталогов:

${WORKDIR}/temp содержит журналы сборки для каждой задачи, файлы run для каждой выполненной задачи и файл log.task_order, указывающий порядок выполнения задач;
${WORKDIR}/image содержит вывод задачи do_install, соответствующей ее переменной ${D};
${WORKDIR}/pseudo содержит псевдобазу данных и журнал для всех задач pseudo в задании.
${WORKDIR}/sysroot-destdir содержит вывод задачи do_populate_sysroot;
${WORKDIR}/package содержит вывод задачи do_package да разделения по отдельным пакетам;
${WORKDIR}/packages-split содержит вывод задачи do_package после разделения по пакетам с каталогами для каждого пакета, созданного заданием;
${WORKDIR}/recipe-sysroot заполняется зависимостями для цели задания и выглядит подобно целевой файловой системе, включая библиотеки, с которыми заданию может потребоваться связь (например, библиотека C);
${WORKDIR}/recipe-sysroot-native заполняется естественными зависимостями задания и содержит инструменты, требуемые для сборки задания (например, компилятор autoconf, libtool и т. п.).
${WORKDIR}/build применяется лишь для заданий, поддерживающих сборки, где исходный код отделен от результатов; система OE использует этот каталог в качестве отдельного каталога сборки (${B}).

5.2.24. `build/tmp/work-shared/`

Для эффективности система сборки OE создает и использует этот каталог для хранения заданий, использующих общий с другими заданиями рабочий каталог. На практике это применяется для gcc и вариантов (gcc-cross, libgcc, gcc-runtimeи т. п.).

5.3. Метаданные – `meta/`

5.3.1. `meta/classes/`

Этот каталог содержит файлы классов *.bbclass, включающие многократно используемый пакетами код. Каждый пакет наследует класс base.bbclass. Примером другого важного наследуемого класса является autotools.bbclass, теоретически позволяющий любому пакету, основанному на autotools работать с YP без больших усилий. Класс kernel.bbclass содержит базовый код и функции для работы с ядром Linux. Такие функции как генерация образов или подготовка пакетов имеют свои классы (image.bbclass, rootfs_*.bbclass и package*.bbclass). Описанию классов посвящена Глава 6. Классы.

5.3.2. `meta/conf/`

Этот каталог содержит основной набор конфигурационных файлов (начиная с bitbake.conf) в которые включены все остальные файлы конфигурации. Операторы include в конце файла bitbake.conf указывают даже файл local.conf. Хотя bitbake.conf устанавливает принятые по умолчанию значения, их можно переопределить в файле local.conf, а также в файле конфигурации машины или дистрибутива.

5.3.3. `meta/conf/machine/`

Этот каталог содержит файлы конфигурации машины. Если установлено MACHINE
= “qemux86”, система сборки OE будет искать файл qemux86.conf в этом каталоге. Каталог include содержит общие данные для разных машин. Если нужна поддержка новой машины в YP, следует заглянуть в этот каталог.

5.3.4. `meta/conf/distro/`

Содержимое этого каталога определяет конфигурацию дистрибутива. Для YP основным файлом служит defaultsetup.conf. Каталог включает версии и определения SRCDATE для настроенных здесь приложений. Примером дополнительной конфигурации может служить poky-bleeding.conf, хотя он в основном наследует конфигурациюPoky.

5.3.5. `meta/conf/machine-sdk/`

Система сборки OE ищет в этом каталоге файлы конфигурации, соответствующие значению SDKMACHINE. По умолчанию в YP включены файлы для 32- и 64-битовых систем x86, поддерживающие некоторые хосты SDK. Можно расширить поддержку SDK, добавив файлы конфигурации в каталоги соответствующих уровней.

5.3.6. `meta/files/`

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

5.3.7. `meta/lib/`

Этот каталог содержит код библиотек OE Python, используемых при сборке.

5.3.8. `meta/recipes-bsp/`

Каталог содержит привязки к конкретному оборудованию или конфигурации для оборудования, такие как u-boot и grub.

5.3.9. meta/recipes-connectivity/

Каталог содержит библиотеки и приложения для коммуникаций с другими устройствами.

5.3.10. meta/recipes-core/

Каталог содержит компоненты, требуемые для сборки базового образа Linux, включая основные зависимости.

5.3.11. meta/recipes-devtools/

Каталог с инструментами, используемыми системой сборки, которые могут применяться и целевой платформой.

5.3.12. `meta/recipes-extended/`

Каталог со второстепенными приложениями, добавляющими свойства к основному образу. Эти приложения могут быть нужны для выполнения требований LSB¹.

5.3.13. `meta/recipes-gnome/`

Каталог, содержащий все, что требуется для приложений GTK+.

5.3.14. `meta/recipes-graphics/`

Каталог с X-библиотеками и другими библиотеками, относящимися к графике.

5.3.15. `meta/recipes-kernel/`

Каталог с ядром и базовыми приложениями и библиотеками, от которых зависит ядро.

5.3.16. `meta/recipes-lsb4/`

Задания, добавленные для поддержки LSB версии 4.x.

5.3.17. `meta/recipes-multimedia/`

Кодеки и утилиты поддержки для звука, изображений и видео.

5.3.18. `meta/recipes-rt/`

Каталог с заданиями для пакетов и образов, применяемых при использовании и тестировании ядер PREEMPT_RT.

5.3.19. `meta/recipes-sato/`

Эталонный дистрибутив Sato, а также связанные с ним приложения и данные конфигурации.

5.3.20. `meta/recipes-support/`

Каталог с заданиями, используемыми другими заданиями, но не включаемыми напрямую в образ (зависимости).

5.3.21. `meta/site/`

Список кэшированных результатов для разных вариантов архитектуры. Поскольку некоторые результаты тестов autoconf не могут быть определены при кросс-компиляции по причине недоступности запуска в live-системе, данные из этого каталога передаются autoconf для разных вариантов архитектуры.

5.3.22. `meta/recipes.txt`

Файл с описанием содержимого recipes-*.

Глава 6. Классы

Файлы классов служат абстракцией функциональности и совместно используются множеством файлов заданий (.bb). Для использования файла класса нужно просто наследовать соответствующий класс в задании. В большинстве случаев наследования класса заданием достаточно для включения функций класса. Однако в некоторых случаях может потребоваться также задание переменных или переопределение принятого по умолчанию поведения.

Любые метаданные, обычно встречающиеся в задании, могут также помещаться в файл класса. Файлы классов используют расширение .bbclass и обычно размещаются в каталоге classes/ каталога meta*/ в дереве исходных кодов. Файлы классов также указываются переменной BUILDDIR (например, build/), как и файлы .conf в каталоге conf. Поиск файлов классов в BBPATH выполняется так же, как и файлов .conf.

В этой главе рассмотрены наиболее важные и полезные классы.

6.1. `allarch.bbclass`

Класс allarch наследуется заданиями, не создающими зависящего от архитектуры вывода. Класс отключает функциональность, которая обычно нужна для создания исполняемых двоичных файлов (например, создание кросс-компилятора и библиотеки C в качестве предварительного условия, а также выделение отладочных символов).

В отличие от заданий для дистрибутивов (например, Debian), задания OE создают пакеты, которые зависят от настройки переменных RDEPENDS и TUNE_PKGARCH
и не должны настраиваться под все архитектуры с помощью allarch. Это происходит даже в тех случаях, когда задание не создает зависимого от архитектуры вывода.

Настройка таких заданий для всех вариантов архитектуры заставляет задачи do_package_write_* tasks иметь разные подписи для машин с разными настройками. Кроме того, происходят ненужные повторы сборки при создании образа для другого значения MACHINE даже при отсутствии изменений в задании.

По умолчанию все задания наследуют классы base и package, которые обеспечивают функциональность, требуемую для создания исполняемых файлов. Если ваше задание, например, производит лишь пакеты с файлами конфигурации, медиа-файлами или сценариями (например, Python и Perl), им нужно наследовать класс allarch.

6.2. `archiver.bbclass`

Класс archiver поддерживает выпуск исходных кодов и других материалов в двоичных файлах (архивах). Дополнительная информация об архивах исходных кодов приведена в разделе Maintaining Open Source License Compliance During Your Product’s Lifecycle [2]. В описании переменной ARCHIVER_MODE представлена информация о флагах переменных (varflags), помогающих создавать архивы.

6.3. `autotools*.bbclass`

Классы autotools* поддерживают пакеты с автоматической настройкой. Пакеты autoconf, automakeиlibtool обеспечивают стандартизацию. Классы определяют набор задач (настройка конфигурации, компиляция и т. п.), которые работают с автоматическими инструментами. Обычно этого достаточно для задания нескольких стандартных переменных и простого наследования автоматических инструментов. Эти классы могут также работать с эмулируемыми автоматическими инструментами (см. раздел Autotooled Package [2]).

По умолчанию классы autotools* используют сборки за пределами дерева (т. е. сборки autotools.bbclass с B != S). Если собираемая заданием программа не поддерживает сборку вне дерева, следует иметь задание, наследующее класс autotools-brokensep,который ведет себя как классautotools но выполняет сборку с B == S. Этот метод полезен, когда поддержка сборки вне дерева отсутствует или не работает. Однако рекомендуется исправить сборку вне дерева и применять ее по возможности.

Полезно иметь некоторое представление о работе задач, определяемых классами autotools*.

do_configure регенерирует сценарий configure (используя autoreconf) и запускает его со стандартным набором инструментов, применяемых при кросс-компиляции. Можно передать в configure дополнительные параметры через переменную EXTRA_OECONF или PACKAGECONFIG_CONFARGS.
do_compile запускает make с аргументами, задающими компилятор и компоновщик. Можно передать дополнительные параметры через переменную EXTRA_OEMAKE.
do_install запускает makeи передает${D} как DESTDIR.

6.4. `base.bbclass`

Класс base отличается тем, что его неявно наследует каждый файл .bb. Этот класс содержит определения стандартных базовых задач для извлечения исходных файлов, их распаковки, настройки (пусто по умолчанию), компиляции (при наличии Makefile), установки (пусто по умолчанию) и упаковки (пусто по умолчанию). Эти классы часто переопределяются или расширяются другими классами, такими как autotools и package. Класс включает также некоторые функции общего назначения (такие как oe_runmake), запускающие make с аргументами из переменной EXTRA_OEMAKE,а также с аргументами, переданными напрямую вoe_runmake.

6.5. `bash-completion.bbclass`

Организует упаковку и зависимости в соответствии с заданиями, собирающими программы, которые включают данные bash-completion².

6.6. `bin_package.bbclass`

Класс bin_package является вспомогательным для заданий, извлекающих содержимое двоичных пакетов (например, RPM) и устанавливающих его. Двоичный пакет распаковывается и создаются новые пакеты в соответствии с заданным выходным форматом. Примером использования этого класса является извлечение и установка фирменных пакетов.

Для RPM и других пакетов, не включающих подкаталогов, следует указать соответствующий параметр сборщика, указывающий подкаталог. Например при использовании в BitBake сборщика Git (git://) параметр subpath ограничивает выбор конкретного пути в дереве. Ниже приведен пример, где применяется ${BP} для извлечения файлов в каталог, ожидаемый заданным по умолчанию значением S:

     SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"

Информация о поддерживаемых BitBake сборщиках приведена в разделе Fetchers [4].

6.7. `binconfig.bbclass`

Класс binconfig помогает корректировать пути к сценариям командного процессора. До широкого распространения pkg-config библиотеки распространялись со сценариями (обычно LIBNAME-config) для получения информации о библиотеках и путях к включаемым файлам, нужным программам. Этот класс помогает заданиям применять такие сценарии. При подготовке система сборки OE устанавливает эти сценарии в каталог sysroots/. Наследование этого класса приводит к тому, что все пути в этих сценариях изменяются так, чтобы корректно указывать каталог sysroots/,чтобы все сборки, использующие сценарий, применяли корректные пути для кросс-компиляции (см. описание переменнойBINCONFIG_GLOB.

6.8. `binconfig-disabled.bbclass`

Дополнительный вариант класса binconfig, отключающий двоичные сценарии настройки путем возврата ошибки (в пользу применения pkg-config для запроса информации). Отключаемые сценарии должны быть указаны в переменной BINCONFIG наследующего класс задания.

6.9. `blacklist.bbclass`

Класс blacklist предотвращает сборку системой OE конкретных пакетов («черный список»). Для использования класса нужно наследовать его глобально и установить переменную PNBLACKLISTдля каждого задания, которое вы хотите включить в «черный список». Задайте значениеPN как флаг переменной (varflag) и укажите причину отказа от сборки, которая указывается, если сборка пакета была запрошена. Например, если вы не хотите собирать задание exoticware, можно указать приведенные ниже строки в файле local.conf или конфигурации дистрибутива

     INHERIT += "blacklist"
     PNBLACKLIST[exoticware] = "Not supported by our organization."

6.10. `bluetooth.bbclass`

Класс bluetooth определяет переменную которая расширяет задание (пакет) базовой поддержкой bluetooth для платформы. Описание работы класса приведено в файле meta/classes/bluetooth.bbclass дерева исходных кодов YP.

6.11. `buildhistory.bbclass`

Класс buildhistory записывает историю сборки по метаданным вывода, которую можно использовать для поиска регрессии и анализа вывода сборки. Информация об истории сборки дана в разделе Maintaining Build Output Quality [2].

6.12. `buildstats.bbclass`

Класс buildstats записывает статистику производительности (время, загрузка процессора, ввод-вывод) для каждой задачи в процессе сборки. При использовании этого класса вывод осуществляется в каталог BUILDSTATS_BASE (по умолчанию ${TMPDIR}/buildstats/). Время работы можно анализировать с помощью сценария scripts/pybootchartgui/pybootchartgui.py, который выдает график процесса сборки и позволяет находить узкие места.

Сбор статистики по умолчанию включается переменной USER_CLASSES в файле local.conf. Для отключения следует удалить buildstats из списка USER_CLASSES.

6.13. `buildstats-summary.bbclass`

При глобальном наследовании этот класс выводит статистику в конце сборки. Для работы нужен класс buildstats.

6.14. `ccache.bbclass`

Класс ccache включает кэш компилятора C/C++ для сборки и служит для небольшого повышения производительности сборки. Однако использование класса может давать побочные эффекты, поэтому применять его не рекомендуется (см. http://ccache.samba.org/).

6.15. `chrpath.bbclass`

Класс chrpath служит «оболочкой» для утилиты chrpath, используемой при сборке заданий nativesdk, cross и cross-canadian для изменения записей RPATH в двоичных файлах с целью сделать их перемещаемыми.

6.16. `clutter.bbclass`

Класс clutter объединяет старший и младший номер версии, а также другие общие элементы, используемые Clutter и связанными заданиями. В отличие от других классов, связанных с конкретными библиотеками, заданиям, создающим другие программы, которые используют Clutter, не требуется наследовать этот класс, если они не применяют такую же схему версий, как Clutter и связанные задания.

6.17. `cmake.bbclass`

Класс cmake разрешает рецепты, для которых применяется система сборки CMake. Можно применять переменную EXTRA_OECMAKE для указания дополнительных опций конфигурации, передаваемых команде cmake.

6.18. cml1.bbclass

Класс cml1 обеспечивает базовую поддержку для систем настройки конфигурации в стиле ядра Linux.

6.19. compress_doc.bbclass

Включает компрессию страниц man и info. Класс предназначен для глобального наследования. По умолчанию применяется сжатие gz (gzip), но можно указать иной механизм с помощью переменной DOC_COMPRESS.

6.20. copyleft_compliance.bbclass

Класс copyleft_compliance представляет исходные коды для целей соответствия лицензиям. Этот класс служит альтернативой классу archiver и продолжает применяться, несмотря на отказ от него в пользу archiver.

6.21. `copyleft_filter.bbclass`

Класс, используемый классами archiver и copyleft_compliance для фильтрации лицензий. Класс copyleft_filter является внутренним и не предназначен для использования напрямую.

6.22. `core-image.bbclass`

Класс core-image обеспечивает базовые определения для заданий core-image-*,
такие как поддержка дополнений в IMAGE_FEATURES.

6.23. `cpan*.bbclass`

Классы cpan* поддерживают модули Perl, задания для которых просты и обычно нужны лишь для указания архива исходных кодов и наследования нужного класса. Сборка применяет 2 метода в зависимости от типа модуля:

для модулей на основе старой системы сборки Makefile.PL нужен класс cpan.bbclass;
для модулей, применяющих систему сборки на основе Build.PL, нужен класс cpan_build.bbclass.

В обоих случаях наследуется класс cpan-base для базовой поддержки Perl.

6.24. `cross.bbclass`

Класс cross обеспечивает поддержку заданий для сборки инструментов кросс-компиляции.

6.25. `cross-canadian.bbclass`

Класс cross-canadian обеспечивает поддержку заданий, собирающих инструменты канадской кросс-компиляции для SDK (см раздел Cross-Development Toolchain Generation [1]).

6.26. `crosssdk.bbclass`

Класс crosssdk обеспечивает поддержку заданий, собирающих инструменты кросс-компиляции для сборки SDK (см раздел Cross-Development Toolchain Generation [1]).

6.27. `debian.bbclass`

Класс debian переименовывает выходные пакеты в соответствии с политикой именования Debian (т. е. glibc становится libc6, а glibc-devel – libc6-dev.). Переименования включает имя библиотеки и версию как часть имени пакета. Если задание создает пакеты для нескольких библиотек (файлы общих объектов типа .so), следует использовать в задании переменную LEAD_SONAME для указания библиотеки, к которой применяется схема именования.

6.28. `deploy.bbclass`

Класс deploy обслуживает развертывание файлов в каталоге DEPLOY_DIR_IMAGE. Основной задачей класса является ускорение этапа развертывания за счет использования общего состояния. Наследующие этот класс задания должны определять свою функцию do_deploy для копирования файлов, разворачиваемых в DEPLOYDIRи использовать addtask для добавления этой задачи в нужное место (обычно после задачи do_compile или do_install). Затем класс обеспечивает размещение файлов из DEPLOYDIR в DEPLOY_DIR_IMAGE.

6.29. `devshell.bbclass`

Класс devshell добавляет задачу do_devshell. Включение этого класса определяется политикой дистрибутива. Использование класса описано в разделе Using a Development Shell [2].

6.30. `devupstream.bbclass`

Класс devupstream использует BBCLASSEXTEND для добавления варианта задания с выборкой из другого URI (например, Git) вместо архива.

     BBCLASSEXTEND = "devupstream:target"
     SRC_URI_class-devupstream = "git://git.example.com/example"
     SRCREV_class-devupstream = "abcd1234"

Добавление этих операторов в задание создаст вариант с DEFAULT_PREFERENCE = “-1”, поэтому нужно будет выбрать используемый вариант задания. Можно внести нужные изменения путем переопределения class-devupstream.

     DEPENDS_append_class-devupstream = " gperf-native"

     do_configure_prepend_class-devupstream() {
        touch ${S}/README
     }

В настоящее время класс поддерживает лишь создание development-вариантов заданий для целевых платформ (не native или nativesdk). Синтаксис BBCLASSEXTEND (devupstream:target) обеспечивает поддержку вариантов native и nativesdk,которая будет добавлена в новых выпусках.

Поддержка других систем контроля версий (например, Subversion) ограничена зависимостями автоматической сборки BitBake (subversion-native).

6.31. `distro_features_check.bbclass`

Класс distro_features_check позволяет отдельным заданиям проверять требуемые и конфликтующие свойства DISTRO_FEATURES. Этот класс обеспечивает поддержку переменных REQUIRED_DISTRO_FEATURES и CONFLICT_DISTRO_FEATURES. Если какое-либо из условий, указанных в задании с помощью этих переменных не выполняется, задание будет пропущено.

6.32. `distutils*.bbclass`

Классы distutils* поддерживают задания для расширений Python версий 2.x. Обычно эти задания нужны лишь для указания архива исходного кода и наследования подходящего класса. При сборке возможны 3 метода в зависимости от выбора автора модуля.

Расширения с автоматизированной сборкой, требующие Autotools и классы на основе distutils в задании.
Расширения со сборкой на основе distutils, требующие класс distutils в своих заданиях.
Расширения со сборкой на основе setuptools,требующие классsetuptools в своих заданиях.

Некоторым классам distutils* нужен класс distutils-common-base для поддержки Python2.

6.33. `distutils3*.bbclass`

Классы distutils3* поддерживают задания для расширений Python версий 3.x. Обычно эти задания нужны лишь для указания архива исходного кода и наследования подходящего класса. При сборке возможны 3 метода в зависимости от выбора автора модуля.

Расширения с автоматизированной сборкой, требующие Autotools и классы на основе distutils в задании.
Расширения со сборкой на основе distutils, требующие класс distutils в своих заданиях.
Расширения со сборкой на основе setuptools3,требующие классsetuptools3 в своих заданиях.

Классы distutils3* наследуют соответствующий класс distutils* или реплицируют его с использованием Python3 (например, distutils3-base наследует класс distutils-common-base, который повторяет distutils-base,но наследует python3native вместо pythonnative).

6.34. `externalsrc.bbclass`

Класс externalsrc поддерживает сборку программ из исходных кодов, находящихся за пределами системы сборки OE. Сборка из внешних источников исключает обычную выборку, распаковку и применение правок. По умолчанию система сборки OE использует переменные S и B для нахождения распакованных исходных кодов и сборки. При наследовании заданием класса externalsrc переменные EXTERNALSRC и EXTERNALSRC_BUILD в конечном итоге задают S и B.

По умолчанию этот класс предполагает, что исходный код поддерживает сборку с использованием переменной B для указания каталога, куда система сборки OE будет помещать созданные объекты. По умолчанию каталог B отделен от дерева исходных кодов (S) и задается в форме ${WORKDIR}/${BPN}/{PV}/.

Дополнительная информация о классе externalsrc приведена в комментариях файла meta/classes/externalsrc.bbclass в дереве исходного кода, а использование класса описано в разделе Building Software from an External Source [2].

6.35. `extrausers.bbclass`

Класс extrausers позволяет применить дополнительные конфигурации пользователей и групп на уровне образа. Наследование этого класса задается глобально или в задании для образа разрешается выполнение дополнительных пользовательских и групповых операций с использованием переменной EXTRA_USERS_PARAMS.

Пользовательские и групповые операции, добавленные с использованием extrausers,не привязаны к конкретным заданиям за пределами задания для образа. Таким образом, операции могут выполняться для образа в целом. Класс useradd добавляет конфигурацию пользователей и групп к конкретному заданию.

Ниже приведен пример использования класса в задании для образа.

     inherit extrausers
     EXTRA_USERS_PARAMS = "\
         useradd -p '' tester; \
         groupadd developers; \
         userdel nobody; \
         groupdel -g video; \
         groupmod -g 1020 developers; \
         usermod -s /bin/sh tester; \
         "

Следующий пример добавляет пользователей tester-jim и tester-sue, а также назначает для них пароль tester01.

     inherit extrausers
     EXTRA_USERS_PARAMS = "\
         useradd -P tester01 tester-jim; \
         useradd -P tester01 tester-sue; \
         "

Еще один пример устанавливает для пользователя root пароль 1876*18:

     inherit extrausers
     EXTRA_USERS_PARAMS = "\
         usermod -P 1876*18 root; \
         "

6.36. `fontcache.bbclass`

Класс fontcache генерирует нужные сценарии пост-установки и пост-удаления (postinst и postrm) для шрифтовых пакетов. Эти сценарии вызывают команду fc-cache (часть Fontconfig) для добавления шрифтов в кэш информации. Поскольку кэш-файлы зависят от архитектуры, fc-cache запускается с использованием QEMU, если сценарии postinst нужно запускать на сборочном хосте при создании образа. Если шрифты устанавливаются не в основном пакете задания, нужно указать в переменной FONT_PACKAGES пакеты, содержащие шрифты.

6.37. `fs-uuid.bbclass`

Класс fs-uuid извлекает UUID из значения ${ROOTFS}, которое должно присутствовать в момент вызова функции. Класс работает только с файловыми системами ext и зависит от tune2fs.

6.38. `gconf.bbclass`

Класс gconf обеспечивает базовую функциональность для заданий, которым нужно устанавливать схемы GConf. Схемы будут помещаться в отдельный пакет (${PN}-gconf), создаваемый автоматически при наследовании этого класса. Этот пакет использует подходящие сценарии пост-установки и пост-удаления (postinst и postrm) для регистрации и дерегистрации схем в целевом образе.

6.39. `gettext.bbclass`

Класс gettext обеспечивает поддержку сборки программ, использующих систему поддержки языков GNU gettext. Всем заданиям, собирающим программы с использованием gettext,нужно наследовать этот класс.

6.40. `gnome.bbclass`

Класс gnome поддерживает задания, собирающие программы из стека GNOME. Этот класс наследует классы gnomebase, gtk-icon-cache, gconf и mime,а также отключает самоанализGobject, когда это приемлемо.

6.41. `gnomebase.bbclass`

Класс gnomebase является базовым для заданий, собирающих программы из стека GNOME. Класс устанавливает SRC_URI для загрузки исходного кода с зеркал GNOME, а также расширяет переменную FILES типовыми путями установки GNOME.

6.42. `gobject-introspection.bbclass`

Обеспечивает поддержку заданий, собирающих программы с самоанализом GObject. Эта функциональность доступна только при наличии свойства gobject-introspection-data в DISTRO_FEATURES, а также qemu-usermode в MACHINE_FEATURES.

Эта функциональность по умолчанию включена и в случае неприменимости ее следует отключать в переменной DISTRO_FEATURES_BACKFILL_CONSIDERED или MACHINE_FEATURES_BACKFILL_CONSIDERED.

6.43. `grub-efi.bbclass`

Класс grub-efi задает относящиеся к режиму grub-efi функции для сборки загружаемых образов. Класс поддерживает перечисленные ниже переменные.

INITRD - указывает список образов файловых систем для конкатенации и применения в качестве стартового RAM-диска (initrd). Необязательна.
ROOTFS - указывает образ файловой системы для включения в качестве корневой. Необязательна.
GRUB_GFXSERIAL - значение 1 задает графический режим и консоль serial.
LABELS - список целей для автоматической настройки конфигурации.
APPEND – список переопределения добавленных строк для каждой метки LABEL.
GRUB_OPTS - дополнительные опции конфигурации, разделенные символом ;. Необязательна.
GRUB_TIMEOUT - время ожидания перед выбором заданной по умолчанию метки. Необязательна.

6.44. `gsettings.bbclass`

Класс gsettings обеспечивает базовую функциональность для заданий, которым требуется устанавливать схемы GSettings (glib). Схемы предполагаются частью основного пакета. Для регистрации и исключения схем из целевого образа добавляются соответствующие сценарии пост-установки и пост-удаления (postinst/postrm).

6.45. `gtk-doc.bbclass`

Класс gtk-doc является вспомогательным для извлечения подходящих зависимостей gtk-doc и отключения gtk-doc.

6.46. `gtk-icon-cache.bbclass`

Класс gtk-icon-cache генерирует соответствующие сценарии пост-установки и пост-удаления (postinst/postrm) для пакетов, использующих GTK+ и пиктограммы установки. Эти сценарии вызывают gtk-update-icon-cache для добавления шрифтов в кэш пиктограмм GTK+. Поскольку кэш-файлы зависят от архитектуры, класс gtk-update-icon-cache работает на основе QEMU, если сценарии пост-установки нужно запускать на сборочном хосте в процессе создания образа.

6.47. `gtk-immodules-cache.bbclass`

Класс gtk-immodules-cache генерирует соответствующие сценарии пост-установки и пост-удаления (postinst/postrm) для пакетов, использующих методы ввода GTK+ для виртуальной клавиатуры. Эти сценарии могут вызывать gtk-update-icon-cache для добавления в кэш методов ввода. Поскольку кэш-файлы зависят от архитектуры, класс gtk-update-icon-cache работает на основе QEMU, если сценарии пост-установки нужно запускать на сборочном хосте в процессе создания образа.

Если модули методов вводе будут устанавливаться не в основном пакете, следует указать эти пакеты в переменной GTKIMMODULES_PACKAGES.

6.48. `gzipnative.bbclass`

Класс gzipnative включает использование естественных версий gzip и pigz вместо версий, доступных на хосте сборки.

6.49. `icecc.bbclass`

Класс icecc поддерживает программу Icecream, упрощающую компиляцию заданий и распределяющую их между удаленными машинами. Класс представляет каталоги с символьными ссылками gcc и g++ на icecc как для естественных, так и для кросс-компиляторов. В зависимости от конфигурации или компиляции система сборки OE добавляет каталоги в начало переменной PATH, а затем использует переменные ICECC_CXX и ICEC_CC, которые указывают на компиляторы g++ и gcc, соответственно. Для кросс-компиляторов класс создает файл tar.gz с инструментарием YP и устанавливает в переменной ICECC_VERSION используемую
версию компилятора, используемого для кросс-разработки. Класс обрабатывает эти три этапа компиляции (native, cross-kernel, target) и создает требуемую среду в файле tar.gz для использования удаленными машинами. Класс также поддерживает генерацию SDK.

Если переменная ICECC_PATH не задана в файле local.conf, класс пытается найти двоичный файл icecc для использования. Если переменная ICECC_ENV_EXEC установлена в local.conf, ей следует указывать пользовательский сценарий icecc-create-env. Если переменная не указывает такой сценарий, система сборки использует принятый по умолчанию из задания icecc-create-env-native.bb. Этот сценарий изменен по сравнению с распространяемым в icecc.

Если не нужно применять распределенную компиляцию Icecream к определенным заданиям или классам, можно поместить их в «черный список» с помощью переменных ICECC_USER_PACKAGE_BL и ICECC_USER_CLASS_BL в файле local.conf. Это приведет к локальной обработке таких заданий и классов системой сборки OE.

Кроме того, можно указать с помощью переменной ICECC_USER_PACKAGE_WL в local.conf задания для форсированного применения icecc в заданиях с пустой переменной PARALLEL_MAKE.

Наследование класса icecc меняет все подписи sstate, поэтому при наличии в команде разработки выделенной системы сборки, которая заполняет STATE_MIRRORS и желании многократно использовать sstate из STATE_MIRRORS, наследовать класс icecc должны все разработчики или никто из них.

На распределенном уровне при наследовании класса icecc нужно обеспечить начало работы всех сборщиков с общими подписями sstate. После наследования класса можно отключить это свойство, как показано ниже.

     INHERIT_DISTRO_append = " icecc"
     ICECC_DISABLED ??= "1"

Такой подход обеспечивает использование всеми одних подписей, но требует от каждого, кто хочет применять Icecream включить это свойство в файле local.conf с помощью строки ICECC_DISABLED = “”.

6.50. `image.bbclass`

Класс image помогает создавать образы в разных форматах. Сначала создается корневая файловая система с использованием одного из файлов rootfs*.bbclass (в зависимости от используемого формата пакетов), затем создается один или несколько файлов с образами. Типы образов определяются переменной IMAGE_FSTYPES, а список пакетов, включаемых в образ, задает переменная IMAGE_INSTALL.

Настройка образов описана в разделе Customizing Images [2], а их создание – в разделе Images [1].

6.51. `image-buildinfo.bbclass`

Класс image-buildinfo записывает информацию в каталог /etc/build целевой файловой системы.

6.52. `image_types.bbclass`

Класс image_types определяет все типы стандартного вывода образов, которые могут быть указаны в переменной IMAGE_FSTYPES. Этот класс может служить в качестве справки о добавлении поддержки вывода пользовательских типов образов.

По умолчанию класс image автоматически включает image_types. Класс image использует переменную IMGCLASSES, как показано ниже.

IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
IMGCLASSES += "image_types_wic"
IMGCLASSES += "rootfs-postcommands"
IMGCLASSES += "image-postinst-intercepts"
inherit ${IMGCLASSES}

Класс image_types также обслуживает преобразование и сжатие образов.

Для сборки образа VMware VMDK нужно добавить wic.vmdk в переменную IMAGE_FSTYPES. Похожая операция выполняется для создания образов vdi³ и qcow2⁴.

6.53. `image-live.bbclass`

Этот класс контролирует сборку «живых» (live) образов (HDDIMG и ISO), содержащих syslinux для унаследованной загрузки, а также загрузчик (bootloader), заданный в EFI_PROVIDER, если MACHINE_FEATURES содержит efi. Обычно этот класс напрямую не используется, а добавляется значение live в IMAGE_FSTYPES.

6.54. `image-mklibs.bbclass`

Класс image-mklibs разрешает использование в задаче do_rootfs утилиты mklibs, оптимизирующей размер библиотек в образе. По умолчанию класс включается в файле local.conf.template с использованием переменной USER_CLASSES.

     USER_CLASSES ?= "buildstats image-mklibs image-prelink"

6.55. `image-prelink.bbclass`

Класс image-mklibs разрешает использование в задаче do_rootfs утилиты prelink, оптимизирующей динамическую компоновку общих библиотек для снижения времени запуска исполняемых файлов. По умолчанию класс включается в файле local.conf.template с использованием переменной USER_CLASSES.

     USER_CLASSES ?= "buildstats image-mklibs image-prelink"

6.56. `insane.bbclass`

Класс insane добавляет в процесс генерации пакетов этап проверки качества системой сборки OE. Выполняется набор тестов для обнаружения основных проблем, возникающих в процессе работы. Включение этого класса обычно определяет политика дистрибутива.

Можно настроить проверку работоспособности с выдачей при отказах предупреждений или сообщений об ошибках. Обычно при первом отказе конкретного теста выдается предупреждение, а последующие считаются ошибками, когда метаданные известны и корректны. Глава 10. Ошибки и предупреждения тестов QA описывает все предупреждения и сообщения об ошибках, которые могут выдаваться в принятой по умолчанию конфигурации.

Переменные WARN_QA и ERROR_QA управляют поведением при проверке на глобальном уровне (уровень конфигурации дистрибутива). Можно пропустить одну или несколько проверок, указав их в переменной INSANE_SKIP. Например, для пропуска проверки символьных ссылок для файлов .so в задании для основного пакета добавляется INSANE_SKIP_${PN} += “dev-so”. Следует помнить об переопределениях имен пакетов (в примере ${PN}).

Проверки QA служат для обнаружения имеющихся и возможных проблем в упакованном выводе. Поэтому при отключении проверок следует соблюдать осторожность.

Ниже приведен список всех тестов, которые можно указывать в переменных WARN_QA и ERROR_QA.

already-stripped

Проверяет удаление отладочных символов до их исключения системой сборки. Вырезание отладочных символов нормально для обычных пакетов. Для того, чтобы отладка работала на платформах, использующих пакеты -dbg, вырезание отладочных символов должно быть отключено.

arch

Проверяет тип ELF⁵, размер, порядок битов всех двоичных файлов на предмет соответствия целевой архитектуре. Отказ теста говорит о несовместимости двоичного файла. Тест может показывать использование непригодного компилятора или опция компиляции. Для некоторых программ (например, загрузчиков) может потребоваться обход этого теста.

buildpaths

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

build-deps

Проверяет соответствие зависимостей при сборке, заданных в DEPENDS (кроме RDEPENDS), или зависимостей на уровне задачи зависимостям, заданным для работы (runtime). Такая проверка полезна, в частности, для определения моментов обнаружения и добавления runtime-зависимостей в процессе упаковки. Если в метаданных не задано явных зависимостей, на этапе упаковки будет поздно обеспечивать создание зависимостей и процесс может установки пакета в образ завершиться ошибкой при выполнении задачи do_rootfs, поскольку обнаруженные автоматически зависимости не выполнены. Примером может служить автоматическое добавление зависимостей классом update-rc.d в пакете initscripts-functions для пакетов, которые устанавливают сценарии инициализации, ссылающиеся на файл /etc/init.d/functions. Заданию следует включать явные RDEPENDS для пакетов от initscripts-functions, чтобы система сборки OE могла гарантировать, что задание initscripts действительно собрано и пакет initscripts-functions доступен.

compile-host-path

Проверяет журнал do_compile на предмет наличия путей на сборочном хосте, используемых при сборке заданий. Наличие таких путей может приводить к засорению хоста выводом сборки.

debug-deps

Проверяет независимость всех пакетов, кроме -dbg, от отладочных пакетов -dbg (зависимость может привести к ошибкам упаковки).

debug-files

Проверяет наличие в каталогах .debug посторонних (не относящихся к пакетам -dbg) файлов. Все отладочные файлы должны находиться в пакетах -dbg.

dep-cmp

Проверяет наличие недействительных операторов сравнения версий в зависимостях между пакетами при работе (т. е. в переменных RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RREPLACES, RCONFLICTS). Некорректное сравнение может вызывать отказы и нежелательное поведение при передаче менеджеру пакетов.

desktop

Запускает программу desktop-file-validate для проверки всех файлов .desktop на предмет соответствия их содержимого спецификации файлов .desktop.

dev-deps

Проверяет независимость всех пакетов, кроме -dev и -staticdev от пакетов -dev, для предотвращения ошибок упаковки.

dev-so

Проверяет, что символьные ссылки .so размещаются в пакетах dev, а не в каких-либо иных. В общем случае такие ссылки полезны лишь для пакетов разработки, поэтому их корректно размещать в пакетах -dev. В некоторых редких случаях для динамически загружаемых модулей такие ссылки применяются в основном пакете.

file-rdeps

Проверяет выполнение зависимостей на уровне файлов, идентифицированных системой сборки OE. Например, сценарий оболочки может начинаться со строки #!/bin/bash, которая будет транслироваться в зависимость от файла /bin/bash. Из трех менеджеров пакетов, поддерживаемых системой сборки OE, лишь RPM напрямую обрабатывает зависимости на уровне файлов, автоматически преобразуя их в зависимости от пакетов, содержащих нужные файлы. Однако отсутствие такой функциональности в других менеджерах пакетов не означает необходимости преобразования зависимостей. Эта проверка QA пытается обеспечить наличие явно созданных RDEPENDS для обработки всех зависимостей на уровне файлов, найденных в файлах пакета.

files-invalid

Проверяет наличие в переменной FILES наличие недопустимых значений с //.

host-user-contaminated

Проверяет, что ни один из созданных заданием пакетов не содержит файлов за пределами /home с идентификаторами пользователя и группы, соответствующими пользователю, применяющему BitBake. Наличие таких файлов обычно означает их установку с некорректными UID/GID, поскольку идентификаторы на целевой платформе не зависят от идентификаторов на хосте. Дополнительная информация приведена в описании задачи do_install task.

incompatible-license

Сообщает о пакетах, исключенных из сборки по причине наличия лицензии, указанной в INCOMPATIBLE_LICENSE.

install-host-path

Проверяет журнал do_install для указания использования путей к местоположению на сборочном хосте. Использование таких путей может приводить в «загрязнению» хоста выводом сборки.

installed-vs-shipped

Сообщает о файлах, установленных задачей do_install, но не включенных ни в один пакет через переменную FILES. Не входящие в пакеты файлы не могут присутствовать в образе на последующих этапах сборки. В идеальном случае все установленные файлы должны включаться в те или иные пакеты. Не включенные в пакеты файлы можно удалить в конце задачи do_install, если они не нужны ни одному из пакетов.

invalid-chars

Проверяет, что переменные метаданных DESCRIPTION, SUMMARY, LICENSE и SECTION в задании не содержат символов, отличных от UTF-8. Некоторые менеджеры пакетов не поддерживают такие символы.

invalid-packageconfig

Проверяет отсутствие не определенных свойств в переменной PACKAGECONFIG. Например, любых имен foo, для которых не существует форма PACKAGECONFIG[foo] = “…”

la

Проверяет файлы .la на предмет наличия в путях TMPDIR. Любой файл .la в таком пути является некорректным, поскольку libtool добавляет корректный префикс sysroot при автоматическом использовании самих файлов.

ldflags

Обеспечивает компоновку двоичных файлов с опциями LDFLAGS, предоставленными системой сборки. Если этот тест не проходит, следует проверить передачу переменной LDFLAGS команде компоновщика.

libdir

Проверяет установку библиотек в некорректные (возможно, жестко заданные) пути. Например, этот тест будет находить задание, которое устанавливает /lib/bar.so при ${base_libdir} lib32. Другим примером является задание, устанавливающее /usr/lib64/foo.so при ${libdir} /usr/lib.

libexec

Проверяет наличие в пакете файлов в /usr/libexec. Эта проверка не выполняется, если переменная libexecdir явно указывает /usr/libexec.

packages-list

Проверяет многократное включение пакета в переменную PACKAGES, что может вызывать проблемы при подготовке пакетов.

perm-config

Указывает строки с непригодным форматом в fs-perms.txt.

perm-line

Указывает строки с непригодным форматом в fs-perms.txt.

perm-link

Указывает строки в файле fs-perms.txt задающие link, когда указанная цель уже существует.

perms

В настоящее время не используется (резерв).

pkgconfig

Проверяет файлы .pc на предмет наличия путей TMPDIR/WORKDIR. Любой файл .pc file, содержащий такие пути, является некорректным, поскольку pkg-config добавляет корректный префикс sysroot при обращении к файлам.

pkgname

Проверяет отсутствие у всех пакетов из PACKAGES имен с недопустимыми символами (кроме 0-9, a-z, ., +, и -).

pkgv-undefined

Проверяет, установлена ли переменная PKGV во время выполнения задачи do_package.

pkgvarcheck

Проверяет переменные RDEPENDS, RRECOMMENDS, RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES, FILES, ALLOW_EMPTY, pkg_preinst, pkg_postinst, pkg_prerm и pkg_postrm на предмет установок, не являющихся специфическими для пакета. Использование этих переменных без связанного с пакетом суффикса может приводить к неоправданному усложнению зависимостей других пакетов в том же задании и другим побочным эффектам.

pn-overrides

Проверяет отсутствие значения имени (PN) задания в переменной OVERRIDES. Если задание названо так, что его значение PN соответствует имеющемуся в OVERRIDES (например, PN совпадает с MACHINE или DISTRO), это может приводить к неожиданным последствиям, например, назначения вида FILES_${PN} = “xyz” фактически превратятся в FILES = “xyz”.

rpaths

Проверяет rpaths в исполняемых файлах на предмет наличия путей системы сборки, таких как TMPDIR. При наличии таких путей будут переданы неверные опции -rpath в команды компоновщика и в исполняемых файлах могут возникнуть проблемы безопасности.

split-strip

Сообщает об отказах при выделении или удалении отладочных символов из исполняемых файлов.

staticdev

Проверяет наличие статических библиотек (*.a) а пакетах, не являющихся staticdev.

symlink-to-sysroot

Проверяет наличие в пакетах символьных ссылок на каталог TMPDIR сборочного хоста. Такие ссылки будут не пригодны при работе на целевой системе.

textrel

Проверяет наличие в исполняемых файлах ELF перемещений (relocation) в их разделах .text, что может влиять на производительность работы. При наличии таких перемещений система сборки выдает сообщение, описанное в параграфе 10.2. Ошибки и предупреждения.

useless-rpaths

Проверяет в исполняемых файлах пути загрузки динамических библиотек (rpath), которые по умолчанию на стандартных системах ищет компоновщик (например, /lib и /usr/lib). Хотя эти пути не будут вызывать проблем, они не требуются и будут занимать пространство.

var-undefined

Сообщает о важных для подготовки пакетов переменных (WORKDIR, DEPLOY_DIR, D, PN, PKGD), которые не определены во время задачи do_package.

version-going-backwards

При включенной истории сборки сообщается, когда записываемый пакет имеет более низкую версию, чем записанный ранее одноименный пакет. Если выходные пакеты помещаются в хранилище и обновляете с его помощью целевую систему, снижение версии может привести к тому, что целевая система не «обновит» этот пакет. Если в целевой системе не применяется обновление через сеть, можно не думать об этой проблеме.

xorg-driver-abi

Проверяет во всех пакетах с драйверами Xorg наличие зависимости ABI. Задание xserver-xorg обеспечивает имена драйверов ABI. Все драйверы должны зависеть от версии ABI, с которой они собраны. Задания для драйверов, включающие файл xorg-driver-input.inc или xorg-driver-video.inc, будут получать версию автоматически. Поэтому нужно лишь явно добавить зависимости для заданий.

6.57. `insserv.bbclass`

Класс insserv использует утилиту insserv для обновления других символьных ссылок в /etc/rc?.d/ внутри образа на основе зависимостей, заданных заголовками LSB в сценариях init.d.

6.58. `kernel.bbclass`

Класс kernel отвечает за сборку ядер Linux и содержит код для сборки деревьев ядра. Нужные заголовки собираются в каталоге STAGING_KERNEL_DIR, чтобы можно было собрать внешние модули с помощью класса module.

Это означает, что каждый собираемый модуль ядра пакуется отдельно и создаются зависимости между модулями путем анализа modinfo. Если требуются все модули, установка пакета kernel-modules обеспечивает инсталляцию всех пакетов с модулями и другими пакетами ядра, такими как kernel-vmlinux.

Логика класса kernel позволяет встраивать образ файловой системы initramfs при сборке образа ядра (см. раздел Building an Initial RAM Filesystem (initramfs) Image [2]).

Классы kernel и module используют внутри себя другие классы, включая kernel-arch, module-base и linux-kernel-base.

6.59. `kernel-arch.bbclass`

Класс kernel-arch устанавливает переменную окружения ARCH для компиляции ядра Linux (включая модули).

6.60. `kernel-devicetree.bbclass`

Класс kernel-devicetree, наследующий kernel, поддерживает генерацию дерева устройств.

6.61. `kernel-fitimage.bbclass`

Класс kernel-fitimage обеспечивает поддержку образов zImage.

6.62. `kernel-grub.bbclass`

Класс kernel-grub обновляет область и меню загрузки с ядром в качестве приоритетного механизма загрузки при установке RPM обновления ядра на развернутой платформе.

6.63. `kernel-module-split.bbclass`

Класс kernel-module-split обеспечивает базовые функции для разделения модулей ядра Linux в отдельные пакеты.

6.64. `kernel-uboot.bbclass`

Класс kernel-uboot поддерживает сборку образов из репозиториев ядра в стиле vmlinux.

6.65. `kernel-uimage.bbclass`

Класс kernel-uimage поддерживает упаковку uImage.

6.66. `kernel-yocto.bbclass`

Класс kernel-yocto обеспечивает базовую функциональность для сборки из репозиториев со стилем ядра linux-yocto.

6.67. `kernelsrc.bbclass`

Класс kernelsrc устанавливает исходные коды и версию ядра Linux.

6.68. `lib_package.bbclass`

Класс lib_package поддерживает задания, собирающие библиотеки и создающие двоичные исполняемые файлы, которые по умолчанию не следует устанавливать вместе с библиотекой. Эти исполняемые двоичные файлы добавляются в отдельный пакет ${PN}-bin.

6.69. `libc*.bbclass`

Классы libc* поддерживают задания, собирающие пакеты с libc:

libc-common обеспечивает базовую поддержу сборки с использованием libc;
libc-package обеспечивает поддержу сборки с использованием glibc и eglibc.

6.70. `license.bbclass`

Класс license обеспечивает создание манифеста лицензий и исключение лицензий. Класс включен по умолчанию через принятое по умолчанию значение переменной INHERIT_DISTRO.

6.71. `linux-kernel-base.bbclass`

Класс linux-kernel-base обеспечивает базовую функциональность для заданий, которые собираются из дерева исходных кодов ядра Linux, не включая сборку самого ядра. Например, задание perf наследует этот класс.

6.72. `linuxloader.bbclass`

Обеспечивает функцию linuxloader(), сообщающую динамический загрузчик/компоновщик, обеспечиваемый платформой. Значение функции используется множеством других классов.

6.73. `logging.bbclass`

Обеспечивает стандартные функции оболочки, используемые для записи в журнал сообщений BitBake с различными уровнями важности (bbplain, bbnote, bbwarn, bberror, bbfatal, bbdebug). Класс включен по умолчанию, поскольку наследуется классом base.

6.74. `meta.bbclass`

Класс meta наследуется заданиями, которые сами не собирают пакетов, но служат мета-целью для других заданий.

6.75. `metadata_scm.bbclass`

Класс metadata_scm обеспечивает функциональность для запроса ветви и выпуска репозитория SCM. Класс base применяет этот класс для печати выпуска каждого задания перед его сборкой. Класс metadata_scm включен по умолчанию, поскольку наследуется классом base.

6.76. `migrate_localcount.bbclass`

Класс migrate_localcount проверяет и инкрементирует данные localcount в задании.

6.77. `mime.bbclass`

Класс mime создает нужные сценарии пост-установки и пост-удаления (postinst/postrm) для пакетов, устанавливающих файлы типов MIME. Эти сценарии вызывают update-mime-database для добавления типов MIME в общую базу данных.

6.78. `mirrors.bbclass`

Класс mirrors организует некоторые стандартные записи MIRRORS для зеркал исходного кода, которые обеспечивают резервные пути при недоступности репозитория, заданного в SRC_URI. Класс включен по умолчанию, поскольку наследуется классом base.

6.79. `module.bbclass`

Класс module обеспечивает поддержку сборки внешних (out-of-tree) модулей ядра Linux. Этот класс наследует классы module-base и kernel-module-split, а также реализует задачи do_compile и do_install. Класс обеспечивает все, что нужно для сборки и упаковки модулей ядра.

Базовая информация о сборке внешних модулей ядра приведена в разделе Incorporating Out-of-Tree Modules [3].

6.80. `module-base.bbclass`

Класс module-base обеспечивает базовые функции сборки модулей ядра Linux. Обычно задание для сборки программы, включающей один или несколько модулей ядра и имеющей свои средства сборки, наследует этот класс , а не класс module.

6.81. `multilib*.bbclass`

Класс multilib* обеспечивает поддержку сборки библиотек с оптимизацией для разных платформ и для разной архитектуры с установкой всех библиотек в один образ. Информация о работе с множеством библиотек приведена в разделе Combining Multiple Versions of Library Files into One Image [2].

6.82. `native.bbclass`

Класс native обеспечивает базовую функциональность для заданий, собирающих инструменты, которые будут работать на хосте сборки. Задание для сборки инструментов, работающих на этом хосте, можно создать двумя способами.

Задание myrecipe-native.bb, наследующее класс native. В этом случае нужно указать оператор inherit для класса native в задании после всех других операторов inherit, чтобы класс native наследовался последним. Имя для такого задания должно иметь форму myrecipe-native.bb, поскольку другие формы именования могут создавать конфликты с имеющимся кодом, который зависит от согласованного именования.
Задание для целевой платформы, содержащее строку BBCLASSEXTEND = “native”. Внутри этого задания указываются переопределения _class-native и _class-target для уточнения функциональности, относящейся к заданию для хоста или целевой платформы.

В обоих вариантах используется класс native. Преимущество второго метода заключается в том, что он не требует двух раздельных заданий для хоста сборки и целевой платформы. Совпадающие части задания автоматически становятся общими.

6.83. `nativesdk.bbclass`

Класс nativesdk обеспечивает базовую функциональность для заданий, собирающих инструменты, которые будут работать как часть SDK (т. е. на SDKMACHINE). Задание можно создать двумя разными способами.

Задание nativesdk-myrecipe.bb, наследующее класс nativesdk. В этом случае нужно указать оператор inherit для класса nativesdk в задании после всех других операторов inherit, чтобы этот класс наследовался последним. Имя для такого задания должно иметь форму nativesdk-myrecipe.bb, поскольку другие формы именования могут создавать конфликты с имеющимся кодом, который зависит от согласованного именования.
Задание, содержащее строку BBCLASSEXTEND = “nativesdk”. Внутри этого задания указываются переопределения _class-nativesdk и _class-target для уточнения функциональности, относящейся к заданию для SDK или целевой платформы.

В обоих вариантах используется класс nativesdk. Преимущество второго метода заключается в том, что он не требует двух раздельных заданий для SDK и целевой платформы. Совпадающие части задания автоматически становятся общими.

6.84. `nopackages.bbclass`

Отключает подготовку пакетов для заданий и классов, где пакеты не требуются.

6.85. `npm.bbclass`

Обеспечивает поддержку сборки программ Node.js из NPM ⁶. В настоящее время задания, наследующие этот класс, должны применять сборщик npm:// для установки зависимостей и автоматической подготовки пакетов. Работа с пакетами NPM описана в разделе Creating Node Package Manager (NPM) Packages [2].

6.86. `oelint.bbclass`

Класс oelint задает устаревший инструмент проверки lint из meta/classes в каталоге исходных кодов. Имеется много классов, которые могут быть полезны в OE-Core, но в реальности никогда не применяются на этом уровне. Класс oelint является одним из таких классов. Однако информация о нем может снизить число разных версий похожих классов на разных уровнях.

6.87. `own-mirrors.bbclass`

Класс own-mirrors упрощает настройку своих зеркал в переменной PREMIRRORS, в соответствии с которой выполняется выборка до обращения кSRC_URI в каждом задании. Для использования этого класса его нужно наследовать глобально и задать переменную SOURCE_MIRROR_URL, как показано ниже.

     INHERIT += "own-mirrors"
     SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"

В переменной SOURCE_MIRROR_URL можно указать лишь один идентификатор URL.

6.88. `package.bbclass`

Этот класс поддерживает базовую функциональность создания пакетов из вывода сборки. Код, относящийся к конкретным типам упаковки, содержится в классах package_deb, package_rpm, package_ipk, and package_tar. Последний из этих классов применять не рекомендуется.

Список форматов упаковки можно задать с помощью переменной PACKAGE_CLASSES в файле conf/local.conf каталога сборки. Переменная может включать несколько типов упаковки. Поскольку образы создаются из пакетов, класс упаковки требуется задать для создания образа. Система сборки будет выбирать из списка указанный первым класс.

При необязательной настройке репозитория (источника пакетов) на хосте разработки, который может использоваться DNF, можно устанавливать пакеты из этого источника при работе образа на целевой платформе (см. раздел Using Runtime Package Management [2]).

Выбранный класс для конкретного пакета может влиять на производительность сборки и требуемое пространство. В общем случае сборка пакетов с использованием IPK примерно на треть быстрее сборки с использованием RPM. Это сравнение учитывает полную сборку пакета со всеми зависимостями, собранными заранее. Причина этого заключается в том, что менеджер пакетов RPM создает и обрабатывает больше метаданных, нежели менеджер IPK. Поэтому для небольших систем целесообразно выбрать для PACKAGE_CLASSES значение “package_ipk”.

При выборе менеджера пакетов следует рассмотреть использование RPM с учетом отмеченного ниже.

RPM обеспечивает больше возможностей по сравнению с IPK за счет обработки большего объема метаданных. Например, метаданные включают типы отдельных файлов, контрольные суммы, поддержку «разбросанных» файлов, обнаружение и разрешение конфликтов в системах Multilib, обновление в стиле ACID, и возможность перепаковки для откатов назад.
Для небольших систем дополнительное пространство, занятое Berkeley Database и объем метаданных RPM могут влиять на возможности обновления.

Дополнительные сведения о влиянии класса package приведены в рассылках https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html и https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html

6.89. `package_deb.bbclass`

Класс package_deb поддерживает создание пакетов в формате Debian (.deb), обеспечивая их запись в каталог ${DEPLOY_DIR_DEB}.Этот класс наследуетклассpackage и включается переменной PACKAGE_CLASSES в local.conf.

6.90. `package_ipk.bbclass`

Класс package_ipk поддерживает создание пакетов в формате IPK (.ipk), обеспечивая их запись в каталог ${DEPLOY_DIR_IPK}. Этот класс наследуетклассpackage и включается переменной PACKAGE_CLASSES в local.conf.

6.91. `package_rpm.bbclass`

Класс package_rpm поддерживает создание пакетов в формате RPM (.rpm), обеспечивая их запись в каталог ${DEPLOY_DIR_RPM}. Этот класс наследуетклассpackage и включается переменной PACKAGE_CLASSES в local.conf.

6.92. `package_tar.bbclass`

Класс package_tar поддерживает создание пакетов в форме архивов (tarball), обеспечивая их запись в каталог ${DEPLOY_DIR_TAR}. Этот класс наследуетклассpackage и включается переменной PACKAGE_CLASSES в local.conf.

Класс package_tar нельзя указывать первым в переменной PACKAGE_CLASSES,для образов и SDK должен применяться формат.deb, .ipkили .rpm.

6.93. `packagedata.bbclass`

Класс packagedata обеспечивает базовую функциональность для чтения файлов pkgdata из переменной PKGDATA_DIR. Эти файлы содержат информацию о каждом пакете, создаваемом системой сборки OE.

Этот класс включен по умолчанию, поскольку он наследуется классом package.

6.94. `packagegroup.bbclass`

Класс packagegroup устанавливает принятые по умолчанию значения, пригодные для заданий групп пакетов (PACKAGES, PACKAGE_ARCH, ALLOW_EMPTYи т. п.). Настоятельно рекомендуется наследовать этот класс всем заданиям для групп. Использование класса описано в разделе Customizing Images Using Custom Package Groups [2].

Ранее этот класс носил имя task.

6.95. `patch.bbclass`

Класс patch обеспечивает функциональность наложения исправлений в задаче do_patch. Класс включен по умолчанию, поскольку наследуется классом base.

6.96. `perlnative.bbclass`

Класс perlnative поддерживает использование естественной версии Perl, созданной системой сборки вместо версии, предоставляемой сборочным хостом.

6.97. `pixbufcache.bbclass`

Класс pixbufcache создает нужные сценарии пост-установки и пост-удаления (postinst/postrm) для пакетов, устанавливающих загрузчики pixbuf, которые применяются с gdk-pixbuf. Эти сценарии вызывают update_pixbuf_cache для добавления загрузчиков pixbuf в кэш. Поскольку файлы кэширования зависят от архитектуры, update_pixbuf_cache запускается с использованием QEMU если сценарии пост-установки нужно запускать на сборочном хосте в процессе создания образа. Если загрузчики pixbuf устанавливаются не в основном пакете, следует установить переменную PIXBUF_PACKAGES для указания этих пакетов.

6.98. `pkgconfig.bbclass`

Класс pkgconfig обеспечивает стандартный способ получения информации о заголовках и библиотеках с помощью pkg-config. Этот класс нацелен на интеграцию pkg-config с использующими программу библиотеками. В процессе подготовки BitBake устанавливает данные pkg-config в каталог sysroots/. За счет использования функциональности sysroot в пакете pkg-config классу pkgconfig больше не требуются манипуляции с файлами.

6.99. `populate_sdk.bbclass`

Класс populate_sdk обеспечивает поддержку заданий, содержащих только SDK. Описание сборки инструментов кросс-разработки с применением задачи do_populate_sdk приведено в разделе Building an SDK Installer [7].

6.100. `populate_sdk_*.bbclass`

Классы populate_sdk_* поддерживают создание SDK:

populate_sdk_base – базовый класс для создания SDK со всеми менеджерами пакетов (DEB, RPM, opkg);
populate_sdk_deb - создание SDK с помощью менеджера пакетов Debian;
populate_sdk_rpm - создание SDK с помощью менеджера пакетов RPM;
populate_sdk_ipk - создание SDK с помощью менеджера пакетов opkg (IPK);
populate_sdk_ext - создание расширяемых SDK с помощью со всеми менеджерами пакетов.

Класс populate_sdk_base наследует подходящий класс populate_sdk_* (deb, rpm, ipk) в соответствии с IMAGE_PKGTYPE.

Базовый класс убеждается в наличии всех исходных и целевых каталогов, затем заполняет SDK. После этого класс populate_sdk_base создает две файловых системы sysroot – ${SDK_ARCH}-nativesdkсодержит кросс-компилятор и связанные с ним инструменты, а также цель, включающую корневую файловую систему, которая настроена для образа SDK. Эти два образа размещаются в SDK_OUTPUT,как показано ниже.

${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs

В заключение базовый класс заполнения SDK создает сценарий настройки среды инструментов, архив SDK и установщик. Классы populate_sdk_deb, populate_sdk_rpmиpopulate_sdk_ipk поддерживают соответствующие типы SDK. Эти классы наследуются и применяются классом populate_sdk_base.

Дополнительные сведения о создании инструментария кросс-разработки приведены в разделе Cross-Development Toolchain Generation [1]. Преимущества сборки инструментария кросс-разработки с использованием задачи do_populate_sdk описаны в разделе Building an SDK Installer [7].

6.101. `prexport.bbclass`

Класс prexport обеспечивает функциональность поддержки экспорта значений PR. Класс не предназначен для использования на прямую и включается применением bitbake-prserv-tool export.

6.102. `primport.bbclass`

Класс primport обеспечивает функциональность поддержки импорта значений PR. Класс не предназначен для использования на прямую и включается применением bitbake-prserv-tool import.

6.103. `prserv.bbclass`

Класс prserv обеспечивает функциональность для использования сервиса PR при автоматическом управлении переменной PR в каждом задании. Этот класс включен по умолчанию, поскольку он наследуется классом package,однако система сборкиOE не включает эту функциональность, пока не установлена переменная PRSERV_HOST.

6.104. `ptest.bbclass`

Класс ptest обеспечивает функции для упаковки и установки тестов заданий, собирающих программы для этих тестов.

Этот класс предназначен для наследования индивидуальными заданиями, однако функции класса отключаются, если ptest отсутствует в DISTRO_FEATURES. Тестирование описано в разделе Testing Packages With ptest [2].

6.105. `ptest-gnome.bbclass`

Включает тесты пакетов (ptest) для пакетов GNOME, предназначенных для выполнения с gnome-desktop-testing.

Тестирование описано в разделе Testing Packages With ptest [2].

6.106. `python-dir.bbclass`

Класс python-dir указывает базовую версию и расположение Python, а также расположение пакетов на сайте.

6.107. `python3native.bbclass`

Класс python3native поддерживает применение системой сборки естественной версии Python 3 вместо версии, предоставляемой сборочным хостом.

6.108. `pythonnative.bbclass`

При наследовании заданием класс pythonnative поддерживает использование естественной версии Python, созданной системой сборки, вместо версии, предоставляемой сборочным хостом.

6.109. `qemu.bbclass`

Класс qemu обеспечивает функциональность заданий, которым требуется QEMU или нужно проверить наличие этого эмулятора. Обычно класс применяется при запуске программ для целевых систем на сборочном хосте с использованием режима эмуляции QEMU.

6.110. `recipe_sanity.bbclass`

Класс recipe_sanity проверяет выполнение на хосте предварительных условий, которые могут влиять на сборку (например, установку переменных или наличие программ).

6.111. `relocatable.bbclass`

Класс relocatable обеспечивает перемещение (relocation) для исполняемых файлов, установленных в sysroot. Класс применяется классом chrpath и сам использует классы cross и native.

6.112. `remove-libtool.bbclass`

Класс remove-libtool добавляет в задачу do_install функцию удаления всех файлов .la, установленных libtool, и эти файлы не будут включены в sysroot и целевые пакеты. Если файлы .la нужно установить, задание может переопределить удаление, установив REMOVE_LIBTOOL_LA = “0”. По умолчанию класс remove-libtool не включен.

6.113. `report-error.bbclass`

Файл report-error поддерживает включение инструмента отчетов об ошибках, который позволяет сохранять сведения об ошибках сборки в единой базе данных. Этот класс собирает отладочную информацию для задания, включая версию задания, систему сборки, целевую систему, ветвь, фиксацию и журнальный файл. Эти данные сохраняются в формате JSON в базе ${LOG_DIR}/error-report.

6.114. `rm_work.bbclass`

Класс rm_work class поддерживает удаление временных рабочих каталогов для экономии дискового пространства. Система сборки OE может занимать значительный объем диска в процессе сборки. Частью занятого пространства являются файлы в каталогах ${TMPDIR}/work каждого задания. Как только система сборки создаст для задания пакеты, эти фалы становятся ненужными. Однако по умолчанию система сборки сохраняет их для проверки и возможной отладки. Если файлы нужно удалить для экономии дискового пространства в процессе сборки, можно включить rm_work by добавлением в файл local.conf каталога сборки строки INHERIT += “rm_work”.

Если исходный код размещается вне рабочего каталога задания, включение rm_work может приводить к утрате внесенных в исходный код изменений. Для исключения некоторых заданий из процесса удаления с помощью rm_work можно указать имена этих заданий в файле local.conf с помощью, например, RM_WORK_EXCLUDE += “busybox glibc”.

6.115. `rootfs*.bbclass`

Классы rootfs* поддерживают создание корневой файловой системы для образа и включают:

rootfs-postcommands с определением функций пост-обработки в заданиях для образов;
rootfs_deb для создания корневых файловых систем в образах, собираемых с использованием пакетов .deb;
rootfs_rpm для создания корневых файловых систем в образах, собираемых с использованием пакетов .rpm;
rootfs_ipk для создания корневых файловых систем в образах, собираемых с использованием пакетов .ipk;
rootfsdebugfiles для установки дополнительных файлов со сборочного хоста непосредственно в корневую файловую систему.

Корневая файловая система создается с использованием одного из файлов rootfs*.bbclass в соответствии с переменной PACKAGE_CLASSES. Информация о создании образов корневой файловой системы приведена в разделе Image Generation [1].

6.116. `sanity.bbclass`

Класс sanity проверяет наличие нужных для работы программ на сборочном хосте, чтобы уведомить пользователя о возможных проблемах при сборке. Этот класс также проверяет пользовательскую конфигурацию в файле local.conf для предотвращения ошибок при сборке. Включение этого класса обычно определяется политикой распространения.

6.117. `scons.bbclass`

Класс scons поддерживает задания для сборки программ, использующих систему сборки SCons. переменная EXTRA_OESCONS позволяет задать дополнительные параметры конфигурации, передаваемые команде scons.

6.118. `sdl.bbclass`

Класс sdl поддерживает задания для сборки программ, использующих библиотеку Simple DirectMedia Layer (SDL).

6.119. `setuptools.bbclass`

Класс setuptools поддерживает расширения Python версии 2.x, используемые системами сборки на основе setuptools. Такие задания должны наследовать класс setuptools.

6.120. `setuptools3.bbclass`

Класс setuptools3 поддерживает расширения Python версии 3.x, используемые системами сборки на основе setuptools. Такие задания должны наследовать класс setuptools3.

6.121. `sign_rpm.bbclass`

Класс sign_rpm поддерживает создание подписанных пакетов RPM.

6.122. `sip.bbclass`

Класс sip поддерживает задания для сборки или упаковки привязок Python на основе SIP.

6.123. `siteconfig.bbclass`

Класс siteconfig поддерживает функциональность настройки конфигурации сайта и применяется классом autotools для ускорения задачи do_configure.

6.124. `siteinfo.bbclass`

Класс siteinfo обеспечивает информацию о целевых системах, которая может быть нужна другим классам и заданиям.

В качестве примера рассмотрим инструменты Autotools, которым может потребоваться проверка, выполняемая на целевой аппаратной платформе. Поскольку в общем случае это невозможно при кросс-компиляции, используется информация о сайте для предоставления кэшированных результатов тестирования, что эти проверки можно было пропустить с сохранением корректных значений переменных. Результаты тестов хранятся в каталоге meta/site с сортировкой по таким категориям, как архитектура, порядок битов, используемая библиотека libc. Информация о сайте предоставляет список файлов, содержащих данные, относящиеся к конкретной сборке, в переменной CONFIG_SITE, которая автоматически выбирается инструментами Autotools.

Класс также предоставляет такие переменные, как SITEINFO_ENDIANNESS и SITEINFO_BITS, которые могут применяться в метаданных.

6.125. `spdx.bbclass`

Класс spdx объединяет в реальном масштабе времени сканирование лицензий, генерацию стандартного вывода SPDX и проверку лицензий в процессе сборки.

6.126. `sstate.bbclass`

Класс sstate обеспечивает поддержку общего состояния (sstate). По умолчанию класс включен через заданное по умолчанию значение INHERIT_DISTRO. Дополнительные сведения о sstate даны в разделе Shared State Cache [1].

6.127. `staging.bbclass`

Класс staging устанавливает файлы в отдельные рабочие каталоги заданий дляsysroot.

Задача do_populate_sysroot отвечает за обработку файлов, попадающих в sysroot заданий.
Задача do_prepare_recipe_sysroot устанавливает файлы в рабочие каталоги отдельных заданий (WORKDIR).

Код класса staging достаточно сложен и обычно работает в 2 этапа, описанных ниже.

На первом этапе обрабатываются задания, имеющие файлы, которые хотят использовать другие задания, зависящие от данного. Обычно эти зависимости указываются через задачу do_install в ${D}. Задача do_populate_sysroot копирует часть этих файлов в ${SYSROOT_DESTDIR}. Эти файлы определяются переменными SYSROOT_DIRS, SYSROOT_DIRS_NATIVE и SYSROOT_DIRS_BLACKLIST. Кроме того, задание может дополнительно настроить файлы, объявляя функцию обработки в SYSROOT_PREPROCESS_FUNCS.

Из этих файлов создается объект общего состояния, который помещается в каталог tmp/sysroots-components/. Файлы сканируются на предмет жестко заданных путей с местам исходной установки. Если местоположение найдено в текстовом файле, оно заменяется маркерами и создается список файлов, для которых нужны такие замены. Эти корректировки называют FIXME. Список сканируемых файлов определяет SSTATE_SCAN_FILES.
На втором этапе обрабатываются задания, желающие использовать что-либо из других заданий и задающие зависимость в переменной DEPENDS. Задание будет иметь задачу do_prepare_recipe_sysroot,при выполнении которой создаютсяrecipe-sysroot и recipe-sysroot-native в рабочем каталоге (WORKDIR). Система сборки OE создает жесткие ссылки на копии соответствующих файлов из компонент sysrootв рабочий каталог. Если создание жесткой ссылки невозможно, система сборки использует копии. Затем система сборки преобразует FIXME в пути в соответствии со списком, определенным на первом этапе. В заключение выполняются все файлы из ${bindir} в sysroot, имеющие префикс postinst-. Хотя такие сценарии пост-установки не рекомендуются для общего пользования, они позволяют решать некоторые проблемы, такие как создание пользователей или индексы модулей.

Поскольку у заданий могут быть зависимости вне DEPENDS (например, do_unpack[depends] += "tar-native:do_populate_sysroot"), функция создания sysroot extend_recipe_sysroot добавляется в качестве предварительной для задач, чьи зависимости не указаны в DEPENDS,но работают аналогично.

При установке зависимостей в sysroot код просматривает граф зависимостей и обрабатывает их так же, как зависимости из sstate. Это означает, например, что для естественного инструмента будут добавлены естественные зависимости, но не библиотеки для целевой системы. Применяется тот же код обработки зависимостей sstate, поэтому сборки будут идентичными, независимо от использования sstate. Более точное описание приведено для функции setscene_depvalid() в классе sstate.

Система сборки аккуратно поддерживает манифесты устанавливаемых файлов, чтобы можно было установить любую нужную зависимость. Хэш sstate для установленных элементов также сохраняется, чтобы в случае изменения система сборки могла заново установить элемент.

6.128. `syslinux.bbclass`

Класс syslinux обеспечивает функции syslinux для сборки загружаемых образов и включает несколько переменных.

Необязательная переменнаяINITRD указывает список образов файловых систем для объединения и использования в качестве начального RAM-диска (initrd).
Необязательная переменнаяROOTFSуказывает образ файловой системы для включения как корневой.
AUTO_SYSLINUXMENUвключает создание автоматического меня при установке значения“1”.
LABELSуказывает цели для автоматической настройки конфигурации.
APPENDуказывает строкуappend переопределяемую для каждой цели (label).
SYSLINUX_OPTSуказывает опции для добавления в файлsyslinux (разделяются символом 😉.
SYSLINUX_SPLASHуказывает фон для загрузочного менюVGA при использовании меню загрузки.
SYSLINUX_DEFAULT_CONSOLEуказывает принятую по умолчанию консоль (console=ttyX) для загрузки ядра.
SYSLINUX_SERIALзадает дополнительный последовательный порт или выключает консоль при пустом имени.
SYSLINUX_SERIAL_TTYзадает дополнительный аргумент загрузки ядра“console=tty…”.

6.129. `systemd.bbclass`

Класс systemd поддерживает задания, устанавливающие файлы модулей systemd. Класс не включается, пока значение systemd не добавлено в DISTRO_FEATURES.

В этом классе задание или Makefile (что вызывается в задаче do_install) устанавливает файлы модулей в каталог ${D}${systemd_unitdir}/system. Если устанавливаемые модули входят в пакеты, отличные от основного, в задании нужно установить переменную SYSTEMD_PACKAGESдля указания пакетов, в которых будут установлены файлы.

В переменной SYSTEMD_SERVICE нужно указать имя службы, а также следует использовать переопределение имени пакета, к которому применяется значение. Если значение применяется к основному пакету задания, используется ${PN}. Например, для задания connman указывается SYSTEMD_SERVICE_${PN} = “connman.service”. Для служб устанавливается автоматический запуск при загрузке, пока не задано SYSTEMD_AUTO_ENABLE = “disable”. Дополнительная информация о systemdприведена в разделеSelecting an Initialization Manager [2].

6.130. `systemd-boot.bbclass`

Класс systemd-boot обеспечивает функции для загрузчика systemd-boot при сборке загружаемых образов. Это внутренний класс, не предназначенный для использования напрямую. Этот класс является результатом слияния класса gummiboot из прежних выпусков YP с проектом systemd.

Для использования класса устанавливается EFI_PROVIDER = “systemd-boot”, в результате чего создается автономный загрузчик EFI, независимый от systemd. Этот класс использует и поддерживает переменные SYSTEMD_BOOT_CFG, SYSTEMD_BOOT_ENTRIESиSYSTEMD_BOOT_TIMEOUT. См. также документацию Systemd-boot.

6.131. `terminal.bbclass`

Класс terminal обеспечивает поддержку запуска терминальных сессий. Выбор терминала для сессии задает переменная OE_TERMINAL. Класс terminal применяется другими классами при необходимости запуска терминальной сессии. Например, это делает класс patch в предположении PATCHRESOLVE = user, а также классы cml1 и devshell.

6.132. `testimage*.bbclass`

Классы testimage* поддерживают автоматизированное тестирование образов с использованием QEMU и реального оборудования. Классы обслуживают загрузку теста и запуск образа. Для использования классов нужно их настроить в среде разработки. Рекомендуется использовать переменную IMAGE_CLASSES (а не INHERIT) для наследования класса testimage при автоматизированном тестировании образов.

Тестами служат команды, которые запускаются на целевой системе с помощью ssh. Тесты написаны на языке Python и используют модуль unittest.

Класс testimage.bbclass запускает тесты образа при вызове с помощью команды

$ bitbake -c testimage image

Класс testimage-auto выполняет тестирование образа после его создания (требуется TESTIMAGE_AUTO = 1). Дополнительная информация о тестировании представлена в разделе Performing Automated Runtime Testing [2].

6.133. `testsdk.bbclass`

Поддерживает запуск автоматизированных тестов для SDK при вызове

     $ bitbake -c testsdk image

Рекомендуется использовать переменную IMAGE_CLASSES (а не INHERIT) для наследования класса testimage при автоматизированном тестировании SDK.

6.134. `texinfo.bbclass`

Этот класс нужно наследовать заданиям, при сборке которых вызываются утилиты texinfo. Созданы естественные и кросс-задания для использования фиктивных сценариев, обеспечиваемых texinfo-dummy-native, для повышения производительности. Задания для целевой архитектуры используют настоящие утилиты Texinfo (по умолчанию предоставляются хостом). Если нужно использовать задание Texinfo из состава системы сборки, можно удалить texinfo-native из переменной ASSUME_PROVIDED и makeinfo из SANITY_REQUIRED_UTILITIES.

6.135. `tinderclient.bbclass`

Класс tinderclient представляет результаты сборки внешнему экземпляру Tinderbox. Этот класс не поддерживается.

6.136. `toaster.bbclass`

Класс toaster собирает информацию о пакетах и образах, передавая ее как события, которые может получать пользовательский интерфейс BitBake. Класс включается при работе пользовательского интерфейса Toaster и не предназначен для использования напрямую.

6.137. `toolchain-scripts.bbclass`

Класс toolchain-scripts обеспечивает сценарии, используемые при организации среды для установленных SDK.

6.138. `typecheck.bbclass`

Класс typecheck обеспечивает возможность проверки соответствия значений переменных в конфигурации уровня заданным для них типам. Система сборки OE позволяет определять типы с помощью флагов переменных type, например, IMAGE_FEATURES[type] = “list”.

6.139. `uboot-config.bbclass`

Класс uboot-config обеспечивает поддержку настройки U-Boot для машины, которая указывается в задании как

     UBOOT_CONFIG ??= <default>
     UBOOT_CONFIG[foo] = "config,images"

Можно также указать машину в форме UBOOT_MACHINE = “config”.

6.140. `uninative.bbclass`

Пытается изолировать систему сборки от библиотеки C дистрибутива сборочного хоста, чтобы обеспечить возможность многократного использования элементов общего состояния в разных дистрибутивах хоста. Если этот класс включен, в начале сборки загружается архив с собранной библиотекой C. В эталонном дистрибутиве Poky этот класс включен по умолчанию в файле meta/conf/distro/include/yocto-uninative.inc. Для других дистрибутивов, не основанных на poky также может применяться файл require conf/distro/include/yocto-uninative.inc. Другим вариантом является самостоятельная организация задания uninative-tarball, публикация полученного архива (например, по HTTP) и соответствующая установка переменных UNINATIVE_URL и UNINATIVE_CHECKSUM. Примером может служить файл meta/conf/distro/include/yocto-uninative.inc.

Класс uninative также безоговорочно применяется в eSDK. При сборке расширяемого SDK собирается uninative-tarball и полученный архив включается в SDK.

6.141. `update-alternatives.bbclass`

Класс update-alternatives помогает выбору вариантов при наличии нескольких источников, представляющих одну команду. Такие ситуации возникают, когда несколько команд, обеспечивающих одну или близкие функции, устанавливаются с одним именем. Например, команда ar доступна в busybox, binutils и elfutils. Класс update-alternatives обрабатывает переименование двоичных файлов, позволяя установить множество пакетов без конфликта. Команда ar будет работать независимо от того, какие пакеты установлены или впоследствии удалены. Класс переименовывает двоичные файлы в каждом пакете и создает символьную ссылку на пакет с высшим приоритетом при установке или удалении пакетов.

Для использования класса нужно определить несколько переменных:

ALTERNATIVE;
ALTERNATIVE_LINK_NAME;
ALTERNATIVE_TARGET;
ALTERNATIVE_PRIORITY.

Эти переменные указывают варианты команд, нужные пакету, обеспечивают пути для ссылок, используемые по умолчанию ссылки для целей и т. п. Информация по использованию переменных приведена в комментариях к файлу update-alternatives.bbclass.

Можно использовать команду update-alternatives непосредственно в заданиях, однако с классом в большинстве случаев работать проще.

6.142. `update-rc.d.bbclass`

Класс update-rc.d использует update-rc.d для безопасной установки сценариев инициализации от имени приложений. Система сборки OE заботится о таких деталях, как гарантии остановки сценария перед удалением пакета и запуска при установке. Управляют классом переменные INITSCRIPT_PACKAGES, INITSCRIPT_NAME и INITSCRIPT_PARAMS.

6.143. `useradd*.bbclass`

Классы useradd* поддерживают добавление пользователей или групп для пакетов на целевой платформе. Например, при наличии пакетов с системными службами, которые следует запускать от имени пользователя или группы, можно воспользоваться этими классами для возможности включения этих пользователей или групп. Задание meta-skeleton/recipes-skeleton/useradd/useradd-example.bb в дереве исходных кодов содержит простой пример, показывающий добавление трех пользователей и групп для двух пакетов.

Класс useradd_base обеспечивает базовую функциональность для работы с пользователями и группами. Классы useradd* поддерживают переменные USERADD_PACKAGES, USERADD_PARAM, GROUPADD_PARAMи GROUPMEMS_PARAM. Класс useradd-staticids поддерживает добавление пользователей и групп со статическими значениями идентификаторов uidиgid. По умолчанию система сборки OE назначает значения uid и gid при добавлении пакетами пользователей и групп динамически во время установки пакета. Это хорошо работает для программ, которые не заботятся об окончательных значениях идентификаторов пользователей и групп. Однако при возникновении проблем с использованием недетерминированных значений uid и gidможно переопределить поведение, задав статические идентификаторы. В этом случае системасборкиOE смотрит нужные значения в файлах files/passwd и files/group по путиBBPATH. Для использования статических значений uid и gid нужно задать несколько переменных (USERADDEXTENSION, USERADD_UID_TABLES, USERADD_GID_TABLES, USERADD_ERROR_DYNAMIC).

Класс useradd-staticids не используется напрямую, а включается или отключается через переменную USERADDEXTENSION. Если включить или отключить класс в настроенной системе, в TMPDIR могут оказаться некорректные значения uid и gid,однако удалениеTMPDIR позволяет решить эту проблему.

6.144. `utility-tasks.bbclass`

Класс utility-tasks обеспечивает поддержку вспомогательных задач, применяемых для всех заданий, таких как do_clean и do_listtasks. Класс включен по умолчанию, поскольку он наследуется классом base.

6.145. `utils.bbclass`

Класс utils обеспечивает некоторые полезные функции Python, которые обычно применяются в inline-выражениях Python (например, ${@...}). Класс включен по умолчанию, поскольку он наследуется классом base.

6.146. `vala.bbclass`

Класс vala поддерживает задания, которым нужно собирать программы, написанные с использованием языка Vala.

6.147. `waf.bbclass`

Класс waf поддерживает задания, собирающие программы с использованием системы сборки Waf. Переменная EXTRA_OECONF или PACKAGECONFIG_CONFARGS позволяет задать дополнительные параметры конфигурации, передаваемые Waf.

Глава 7. Задачи

Задачи являются блоками выполнения BitBake. Задания (файлы .bb) применяют задачи для настройки, компиляции и упаковки программ. В этой главе приведен справочник по задачам, определенным в системе сборки OE.

7.1. Обычные задачи сборки заданий

В последующих параграфах рассмотрены обычные задачи, связанные со сборкой заданий. Дополнительные сведения о задачах и зависимостях приведены в разделах Tasks и Dependencies[4].

7.1.1. `do_build`

Используемая по умолчанию задача для всех сборочных заданий, зависящая от других задач, нужных для сборки.

7.1.2. `do_compile`

Компиляция исходного кода. Задача выполняется из каталога, заданного переменной ${B}. По умолчанию эта задача вызывает функцию oe_runmake,если найден файл сборки (Makefile, makefileилиGNUmakefile). В противном случае do_compile не делает ничего.

7.1.3. `do_compile_ptest_base`

Компилирует набор используемых при работе (runtime) тестов, который включен в собираемое задание.

7.1.4. `do_configure`

Настраивает исходные коды выбирая опции конфигурации и сборки для собираемой программы. Задача выполняется в текущем рабочем каталоге, заданном переменной ${B}. По умолчанию эта задача вызывает функцию oe_runmake,если найден файл сборки (Makefile, makefileилиGNUmakefile) и не установлено CLEANBROKEN = “1”. В противном случае do_configure не делает ничего.

7.1.5. `do_configure_ptest_base`

Настраивает набор runtime-тестов, включаемых в собираемые программы.

7.1.6. `do_deploy`

Записывает выходные файлы для развертывания в ${DEPLOY_DIR_IMAGE}. Задача выполняется из текущего рабочего каталога, указанного ${B}. Заданиям, применяющим эту задачу, нужно наследовать класс deploy и записывать вывод в каталог ${DEPLOYDIR}(не следует путать его с${DEPLOY_DIR}). Класс deploy устанавливает do_deploy как задачу с общим состоянием (sstate), которую можно ускорить с помощью механизма sstate, обеспечивающего копирование вывода из ${DEPLOYDIR} в ${DEPLOY_DIR_IMAGE}. Не записывайте вывод напрямую в ${DEPLOY_DIR_IMAGE}, поскольку это нарушит работу sstate.

Задача do_deploy не добавляется по умолчанию и должна указываться вручную. Если нужно запустить задачу после do_compile, можно выполнить

     addtask deploy after do_compile

Добавление do_deploy после других задач выполняется так же. Не нужно добавлять before do_build в команду addtask (хотя это безвредно), поскольку класс base содержит

     do_build[recrdeptask] += "do_deploy"

Дополнительная информация о развертывании приведена в разделе Dependencies [4].

При повторном выполнении задачи do_deploy предыдущий вывод удаляется (очищается).

7.1.7. `do_fetch`

Извлекает исходный код, используя переменную SRC_URI и префикс аргумента для определения нужного сборщика.

7.1.8. `do_image`

Запускает процесс создания образа после того, как система сборки OE выполнит задачу do_rootfs,в которой указываются выбранные для установки приложения, создается корневая файловая система и выполняется пост-обработка. Задача do_image выполняет предварительную обработку образа с помощью IMAGE_PREPROCESS_COMMAND и динамически генерирует при необходимости задачи do_image_*. Дополнительные сведения о создании образов приведены в разделе Image Generation [1].

7.1.9. `do_image_complete`

Завершает процесс генерации образа. Эта задача выполняется после того, как система сборки OE запустит задачу do_image,в которой выполняется предварительная обработка и создается образ с помощью динамически генерируемых задачdo_image_*.

Задача do_image_complete выполня пост-обработку образа с помощью IMAGE_POSTPROCESS_COMMAND. Создание образов описано в разделе Image Generation [1].

7.1.10. `do_install`

Копирование файлов, которые должны быть включены в пакет, в область ${D}. Задача выполняется из каталога, заданного переменной${B}, который служит каталогом компиляции. Задача do_install, как и другие задачи, напрямую или косвенно зависящие от установленных файлов (например do_package, do_package_write_*, do_rootfs), запускаются в fakeroot [1].

При установке файлов нужно соблюдать осторожность в выборе идентификаторов владельца и группы, чтобы для них не были указаны неопределенные значения. Некоторые методы копирования файлов, особенно команда cp с рекурсией, могут сохранять UID и/или GID исходного файла, что обычно нежелательно. Проверка host-user-contaminated позволяет контролировать владельца и группу для файлов.

Ниже перечислены некоторые методы установки файлов.

Утилита install (предпочтительный вариант).
Команда cp с опцией –no-preserve=ownership.
Команда tar с опцией —no-same-owner (см. файл bin_package.bbclass в каталоге meta/classes дерева кодов).

7.1.11. `do_install_ptest_base`

Копирует файлы набора тестов runtime из области компиляции в область хранения.

7.1.12. `do_package`

Анализирует содержимое области ${D} и разделяет его на части по доступным пакетам и файлам. Задача использует переменные PACKAGES и FILES.

Задача do_package вместе с do_packagedata сохраняет некоторые важные метаданные пакетов (см. описание переменной PKGDESTWORK и раздел Automatically Added Runtime Dependencies [1]).

7.1.13. `do_package_qa`

Запускает проверки QA для файлов пакета (см. параграф 6.56. insane.bbclass).

7.1.14. `do_package_write_deb`

Создает пакеты Debian (файлы *.deb) и помещает их в каталог ${DEPLOY_DIR_DEB} в области источника пакетов. Дополнительные сведения об упаковке приведены в разделе Package Feeds [1].

7.1.15. `do_package_write_ipk`

Создает пакеты IPK ( файлы *.ipk) и помещает их в каталог ${DEPLOY_DIR_IPK} в области источника пакетов. Дополнительные сведения об упаковке приведены в разделе Package Feeds [1].

7.1.16. `do_package_write_rpm`

Создает пакеты RPM ( файлы *.rpm) и помещает их в каталог ${DEPLOY_DIR_RPM} в области источника пакетов. Дополнительные сведения об упаковке приведены в разделе Package Feeds [1].

7.1.17. `do_package_write_tar`

Создает архивы (tarball) и помещает их в каталог ${DEPLOY_DIR_TAR} (см. раздел Package Feeds [1]).

7.1.18. `do_packagedata`

Сохраняет метаданные пакеты, созданные задачей do_package в каталоге PKGDATA_DIR для глобального доступа.

7.1.19. `do_patch`

Находит patch-файлы и применяет их к исходному коду. После извлечения и распаковки исходных файлов система сборки использует операторы SRC_URI из задания для поиска и применения исправлений к исходному коду. Система сборки использует переменную FILESPATH для определения принятого по умолчанию набора каталогов поиска patch-файлов. Файлы исправлений по умолчанию используют расширение *.patch или *.diff и хранятся в подкаталоге каталога с файлом задания. Например, задание bluez5 уровня OE-Core (poky/meta) использует каталог poky/meta/recipes-connectivity/bluez5 и включает два patch-файла. В задании bluez5 операторы SRC_URI указывают на исходные файлы и исправления, нужные для сборки пакета.

В случае задания bluez5_5.48.bb операторы применяются SRC_URI из включаемого файла bluez5.inc.

Как отмечено выше, система сборки считает файлы с расширениями .patch и .diff файлами исправлений. Однако можно использовать параметр apply=yes с оператором SRC_URI для указания в качестве исправлений любых файлов.

SRC_URI = " \
          git://path_to_repo/some_package \ file://file;apply=yes \ "

И наоборот, если у вас есть целый каталог patch-файлов и нужно исключить применение части их задачей do_patch,следует использовать параметрapply=no с оператором SRC_URI.

SRC_URI = " \
          git://path_to_repo/some_package \ file://path_to_lots_of_patch_files \ file://path_to_lots_of_patch_files/patch_file5;apply=no \ "

Если все файлы в каталоге имеют расширение .patch или .diff, будут применены все исправления, кроме patch_file5.

Дополнительная информация о применении patch-файлов дана в разделах Patching [1] и Patching Code [2].

7.1.20. `do_populate_lic`

Записывает лицензионную информацию для задания, которая затем собирается при создании образа.

7.1.21. `do_populate_sdk`

Создает структуру файлов и каталогов для устанавливаемого SDK (см. раздел SDK Generation [1]).

7.1.22. `do_populate_sysroot`

Помещает (копирует) часть файлов, установленных задачей do_install в соответствующий каталог sysroot. Информация о доступе к этим файлам из других заданий приведена в описаниях переменных STAGING_DIR*. Каталоги, которые обычно не нужны другим заданиям (например, /etc), по умолчанию не копируются. Копируемые по умолчанию каталоги приведены в описаниях переменных SYSROOT_DIRS*. Значения этих переменных можно изменить в задании, если нужно добавить или исключить каталоги, доступные другим заданиям в процессе сборки.

Задача do_populate_sysroot относится к задачам с общим состоянием (sstate), что позволяет ускорить ее с помощью sstate. При повторном выполнении задачи предшествующий вывод удаляется (очистка).

7.1.23. `do_prepare_recipe_sysroot`

Устанавливает файлы в sysroot отдельных заданий (т. е. recipe-sysroot и recipe-sysroot-native в каталоге ${WORKDIR} на основе зависимостей из DEPENDS). Дополнительная информация приведена в параграфе 6.127. staging.bbclass.

7.1.24. `do_rm_work`

Удаляет рабочие файлы после завершения их использования системой сборки OE (см. параграф 6.114. rm_work.bbclass).

7.1.25. `do_unpack`

Распаковывает исходный код в рабочий каталог, указанный ${WORKDIR}. Переменная S тоже играет роль в выборе окончательного места размещения распакованных файлов. Дополнительная информация о распаковке файлов исходного кода приведена в разделе Source Fetching [1] а также описаниях переменных WORKDIR и S.

7.2. Вызываемые вручную задачи

Описанные в этом разделе задачи обычно запускаются вручную, например, с помощью bitbake -c.

7.2.1. `do_checkpkg`

Обеспечивает информацию о задании, включая «восходящую» версию и статус. Для проверки версии и статуса задания служат приведенные ниже команды devtool (Глава 8. Краткий справочник по работе с devtool).

     $ devtool latest-version
     $ devtool check-upgrade-status

Информация о проверке статуса обновления задания приведена в параграфе 8.9. Проверка статуса обновления задания. Для сборки задачи checkpkg используется опция -c с именем задачи, как показано ниже.

     $ bitbake core-image-minimal -c checkpkg

По умолчанию результат сохраняется в $LOG_DIR (например, $BUILD_DIR/tmp/log).

7.2.2. `do_checkuri`

Проверяет пригодность значения SRC_URI.

7.2.3. `do_clean`

Удаляет все выходные файлы для цели от задачи do_unpack вперед (do_unpack, do_configure, do_compile, do_install, do_package). Задача запускается командой bitbake -c clean recipe.Запуск задачи не удаляет кэш-файлы sstate, поэтому при отсутствии изменений и пересборке задания после очистки, выходные файлы будут просто восстановлены из кэша sstate. Если нужно удалить кэш для задания, должна применяться задача do_cleansstate (bitbake -c cleansstate recipe).

7.2.4. `do_cleanall`

Удаляет все выходные файлы, кэш общего состояния (sstate) и загруженные файлы для цели (содержимое DL_DIR). Задача do_cleanall идентична do_cleansstate за исключением того, что удаляет загруженные исходные файлы. Задача запускается командой bitbake -c cleanall recipe.Обычно задачаcleanall не применяется, если не нужно начать сборку заново с задачи do_fetch.

7.2.5. `do_cleansstate`

Удаляет все выходные файлы и кэш общего состояния (sstate) файлы для цели. Задача do_cleansstate идентична do_clean,но дополнительно удаляет кэш общего состояния(sstate). Задача запускается командой bitbake -c cleansstate recipe.При запускеdo_cleansstate система сборки OE больше не применяет sstate, поэтому гарантируется сборка задания «с нуля».

Задача do_cleansstate не может удалять файлы sstate с удаленного зеркала sstate. Если нужно собрать цель с нуля при использовании удаленных зеркал, нужно задать опцию -f, как показано ниже.

$ bitbake -f -c do_cleansstate target

7.2.6. `do_devpyshell`

Запускает оболочку, в которой интерактивный интерпретатор Python позволяет взаимодействовать со средой сборки BitBake. Из этой оболочки можно напрямую проверять и устанавливать биты из хранилища данных, а также вызывать функции как в среде BitBake. Описание devpyshell приведено в разделе Using a Development Python Shell [2].

7.2.7. `do_devshell`

Запускает оболочку со средой, настроенной на разработку и/или отладку. Работа с оболочкой devshell описана в разделе Using a Development Shell [2].

7.2.8. `do_listtasks`

Перечисляет определенные для цели задачи.

7.2.9. `do_package_index`

Создает или обновляет индекс в области хранилищ пакетов. Эта задача не вызывается командой bitbake -c как другие задачи этого раздела. Поскольку задача предназначена для задания package-index, она вызывается командой bitbake package-index.

7.3. Задачи, связанные с образами

Перечисленные ниже задачи относятся к заданиям для образов.

7.3.1. `do_bootimg`

Создает загружаемый live-образ. Типы образов рассмотрены в описании переменной IMAGE_FSTYPES.

7.3.2. `do_bundle_initramfs`

Объединяет образ initramfs и ядро в один образ (см. CONFIG_INITRAMFS_SOURCE).

7.3.3. `do_rootfs`

Создает корневую файловую систему (см. раздел Image Generation [1]).

7.3.4. `do_testimage`

Загружает образ и выполняет тесты на нем (см. раздел Performing Automated Runtime Testing [2]).

7.3.5. `do_testimage_auto`

Загружает образ и выполняет тесты на нем сразу после сборки. Задача включается установкой TESTIMAGE_AUTO = 1.

Дополнительную информацию можно найти в разделе Performing Automated Runtime Testing [2].

7.4. Задачи, связанные с ядром

Описанные ниже задачи относятся к заданиям для ядра. Некоторые задачи (например, do_menuconfig) применимы также к заданиям, использующим настройку в стиле ядра Linux (например BusyBox).

7.4.1. `do_compile_kernelmodules`

Запускает этап сборки модулей ядра (если нужно), включающий 1) сборку ядра (vmlinux) и 2) модулей (make modules).

7.4.2. `do_diffconfig`

При вызове пользователем эта задача создает файл, содержащий различия между исходной конфигурацией, созданной задачей do_kernel_configme и пользовательской конфигурацией (например, результат do_kernel_menuconfig). Этот файл может служить для создания фрагмента конфигурации, содержащего лишь различия. Задачу можно вызвать командой вида bitbake linux-yocto -c diffconfig.

Дополнительную информацию можно найти в разделе Creating Configuration Fragments [3].

7.4.3. `do_kernel_checkout`

Преобразует недавно распакованные коды ядра в форму, подходящую для системы сборки OE. Поскольку исходные коды ядра могут извлекаться разными способами, задача do_kernel_checkout task обеспечивает четкую рабочую копию ядра с корректным выбором ветви.

7.4.4. `do_kernel_configcheck`

Служит для проверки конфигурации, созданной задачей do_kernel_menuconfig и выводит предупреждения в случае отсутствия запрошенной конфигурации в финальном файле .config или переопределения правил конфигурации во фрагменте аппаратной конфигурации. Задачу можно запустить явно для просмотра вывода с помощью команды bitbake linux-yocto -c kernel_configcheck -f. Дополнительные сведения можно найти в разделе Validating Configuration [3].

7.4.5. `do_kernel_configme`

После наложения правок на ядро с помощью задачи do_patch задача do_kernel_configme собирает и объединяет все фрагменты конфигурации ядра, которые затем могут быть переданы этапу настройки конфигурации. Здесь также применяются опции из заданных пользователем файлов defconfig и режимы настройки --allnoconfig.

7.4.6. `do_kernel_menuconfig`

Вызывается пользователем для работы с файлом .config,используемым для сборки задания linux-yocto и запускает инструмент настройки конфигурации ядра Linux, который позволяет настроить параметры ядра. Эту задачу можно запустить командой bitbake linux-yocto -c menuconfig. Информация о настройке конфигурации ядра приведена в разделе Using menuconfig[3].

7.4.7. `do_kernel_metadata`

Собирает все свойства, нужные для сборки данного ядра, независимо от их источника (SRC_URI или репозиторий Git). После сбора задача преобразует свойства в набор фрагментов конфигурации и patch-файлов, применяемых последующими задачами, такими как do_patch и do_kernel_configme.

7.4.8. `do_menuconfig`

Запускает команду make menuconfig для ядра (см. раздел Using menuconfig [3]).

7.4.9. `do_savedefconfig`

При вызове пользователем создает файл defconfig, который может использоваться вместо принятого по умолчанию. Сохраненный файл defconfig содержит различия между заданным по умолчанию файлом defconfig и внесенные пользователем изменения (с использованием других методов, таких как задача do_kernel_menuconfig). Задачу можно вызвать командой bitbake linux-yocto -c savedefconfig.

7.4.10. `do_shared_workdir`

После компиляции ядра, но до компиляции модулей задача копирует файлы, требуемые для сборки модулей и созданные при сборке ядра, в общий рабочий каталог. После копирования задача do_compile_kernelmodules может собрать модули на следующем этапе.

7.4.11. `do_sizecheck`

После сборки ядра эта задача проверяет размер ядра с вырезанными символами, сравнивая его с переменной KERNEL_IMAGE_MAXSIZE. Если переменная задана и размер ядра превышает ее значение, выдается предупреждение.

7.4.12. `do_strip`

При установленной переменной KERNEL_IMAGE_STRIP_EXTRA_SECTIONS эта задача вырезает заданные переменной разделы из файла vmlinux. Обычно это применяется для исключения таких разделов как .comment для снижения размера ядра.

7.4.13. `do_validate_branches`

После распаковки ядра и перед наложением правок (patch) эта задача проверяет наличие ветвей машины и метаданных, указанных переменной SRCREV. Если ветви не найдены, а переменная AUTOREV не используется, задача do_validate_branches вызывает ошибку сборки.

7.5. Прочие задачи

7.5.1. `do_spdx`

Этап сборки, принимающий исходный код и сканирующий его на удаленном сервере FOSSOLOGY для создания документа SPDX. Задача применима только к классу spdx.

Глава 8. Краткий справочник по работе с `devtool`

Консольный инструмент devtool обеспечивает множество функций для сборки, тестирования и подготовки пакетов. Эта команда доступная вместе с bitbake и является важнейшей частью расширяемых SDK. Здесь приведено краткое описание devtool, а более полные сведения содержатся в разделе Using the Extensible SDK [7].

8.1. Получение справки

Команды devtool организованы подобно Git и включают множество субкоманд для разных функций, которые можно увидеть по команде devtool –help.

     $ devtool -h
     NOTE: Starting bitbake server...
     usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
                    [--color COLOR] [-h]
                    <subcommand> ...

     OpenEmbedded development tool

     options:
       --basepath BASEPATH   Base directory of SDK / build directory
       --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it
                             from the metadata
       -d, --debug           Enable debug output
       -q, --quiet           Print only errors
       --color COLOR         Colorize output (where COLOR is auto, always, never)
       -h, --help            show this help message and exit

     subcommands:
       Beginning work on a recipe:
         add                   Add a new recipe
         modify                Modify the source for an existing recipe
         upgrade               Upgrade an existing recipe
       Getting information:
         status                Show workspace status
         search                Search available recipes
         latest-version        Report the latest version of an existing recipe
         check-upgrade-status  Report upgradability for multiple (or all) recipes
       Working on a recipe in the workspace:
         build                 Build a recipe
         rename                Rename a recipe file in the workspace
         edit-recipe           Edit a recipe file
         find-recipe           Find a recipe file
         configure-help        Get help on configure script options
         update-recipe         Apply changes from external source tree to recipe
         reset                 Remove a recipe from your workspace
         finish                Finish working on a recipe in your workspace
       Testing changes on target:
         deploy-target         Deploy recipe output files to live target machine
         undeploy-target       Undeploy recipe output files in live target machine
         build-image           Build image including workspace recipe packages
       Advanced:
         create-workspace      Set up workspace in an alternative location
         export                Export workspace into a tar archive
         import                Import exported tar archive into workspace
         extract               Extract the source for an existing recipe
         sync                  Synchronize the source tree for an existing recipe
     Use devtool <subcommand> --help to get help on a specific command

Как указано на справочной странице можно получить дополнительные сведения о конкретных командах, указав имя команды и опцию –help.

     $ devtool add --help
     NOTE: Starting bitbake server...
     usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI]
                        [--fetch-dev] [--version VERSION] [--no-git]
                        [--srcrev SRCREV | --autorev] [--srcbranch SRCBRANCH]
                        [--binary] [--also-native] [--src-subdir SUBDIR]
                        [--mirrors] [--provides PROVIDES]
                        [recipename] [srctree] [fetchuri]

     Adds a new recipe to the workspace to build a specified source tree. Can
     optionally fetch a remote URI and unpack it to create the source tree.

     arguments:
       recipename            Name for new recipe to add (just name - no version,
                             path or extension). If not specified, will attempt to
                             auto-detect it.
       srctree               Path to external source tree. If not specified, a
                             subdirectory of
                             /home/scottrif/poky/build/workspace/sources will be
                             used.
       fetchuri              Fetch the specified URI and extract it to create the
                             source tree

     options:
       -h, --help            show this help message and exit
       --same-dir, -s        Build in same directory as source
       --no-same-dir         Force build in a separate build directory
       --fetch URI, -f URI   Fetch the specified URI and extract it to create the
                             source tree (deprecated - pass as positional argument
                             instead)
       --fetch-dev           For npm, also fetch devDependencies
       --version VERSION, -V VERSION
                             Version to use within recipe (PV)
       --no-git, -g          If fetching source, do not set up source tree as a git
                             repository
       --srcrev SRCREV, -S SRCREV
                             Source revision to fetch if fetching from an SCM such
                             as git (default latest)
       --autorev, -a         When fetching from a git repository, set SRCREV in the
                             recipe to a floating revision instead of fixed
       --srcbranch SRCBRANCH, -B SRCBRANCH
                             Branch in source repository if fetching from an SCM
                             such as git (default master)
       --binary, -b          Treat the source tree as something that should be
                             installed verbatim (no compilation, same directory
                             structure). Useful with binary packages e.g. RPMs.
       --also-native         Also add native variant (i.e. support building recipe
                             for the build host as well as the target machine)
       --src-subdir SUBDIR   Specify subdirectory within source tree to use
       --mirrors             Enable PREMIRRORS and MIRRORS for source tree fetching
                             (disable by default).
       --provides PROVIDES, -p PROVIDES
                             Specify an alias for the item provided by the recipe.
                             E.g. virtual/libgl

8.2. Структура уровня `workspace`

Команда devtool использует уровень Workspace, в котором выполняется сборка. Этот уровень не связан с какой-либо конкретной командой devtool, а служит рабочей областью для инструмента. Структура workspace показана на рисунке.

attic

Каталог, создаваемый в случаях, когда devtool хочет что-либо сохранить при выполнении команды devtool reset. Например, можно ввести команду devtool add, изменить задание, а затем вызвать devtool reset и devtool отметит измененные файлы и перенесет их в каталог attic.

README

Информация об уровне workspace и управлении им.

.devtool_md5

Файл контрольной суммы, используемый devtool.

appends

Каталог с файлами *.bbappend, указывающими внешний источник.

conf

Конфигурационный каталог с файлом layer.conf.

recipes

Каталог с заданиями, каждое из которых размещается с своем каталоге, имя которого соответствует имени задания. Программа devtool помещает в эти каталоги файлы .bb для заданий.

sources

Каталог с рабочей копией файлов исходного кода для сборки задания. По умолчанию этот каталог используется в качестве дерева источников, если не задано иного пути к ним. Каталог включает подкаталоги с файлами соответствующих заданий.

8.3. Добавление задания на уровень workspace

Команда devtool add добавляет задание на уровень workspace. Задание не нужно создавать заранее, это сделает devtool. Файлы исходных кодов для задания должны размещаться во внешней области.

Ниже приведен пример, добавляющий задание jackson на уровень workspace и исходными кодами из каталога /home/user/sources/jackson.

$ devtool add jackson /home/user/sources/jackson

Если в момент добавления задания уровня workspace еще не было, команда создаст его и заполнит в соответствии с параграфом 8.2. Структура уровня workspace. Если уровень уже создан, команда devtool add добавит файлы задания и дополнения, а также файлы исходного кода в существующую структуру. Создается файл .bbappend для указания внешнего дерева источников.

Если для задания указаны зависимости при работе, нужно убедиться в наличии соответствующих пакетов на целевой платформе перед попыткой запустить приложение. Если нужных пакетов (например, библиотек) нет на целевой платформе, приложение не сможет работать (8.14. Развертывание программ на целевой машине).

По умолчанию devtool add использует последний выпуск (т. е. master) при извлечении файлов из удаленного URI. В некоторых случаях можно задать выпуск по ветви, тегу или хэш-значению фиксации опциями команды devtool add.

Для задания ветви служит опция --srcbranch (выбирает ветвь warrior)
```
$ devtool add --srcbranch warrior jackson /home/user/sources/jackson
```
Для задания тега или хэш-значения служит опция --srcrev.
```
$ devtool add --srcrev yocto-2.7.1 jackson /home/user/sources/jackson $ devtool add --srcrev some_commit_hash /home/user/sources/jackson
```
В этих примерах выбирается тег yocto-2.7.1 и фиксация с хэшем some_commit_hash.

Если нужно использовать наиболее свежую версию при каждой сборке, следует указать опцию --autorev или -a.

8.4. Извлечение исходного кода для имеющегося задания

Команда devtool extract служит для извлечения исходных кодов имеющегося задания, имя которого (без версии, пути и расширения) должно быть указано в команде вместе с каталогом, куда следует поместить извлеченные файлы. Опции команды позволяют указать ветвь, в которую будет извлекаться код, и управлять сохранением временного каталога.

8.5. Синхронизация дерева исходного кода

Команда devtool sync позволяет синхронизировать исходный код для имеющегося задания. В команде нужно указать имя задания (без версии, пути и расширения) вместе с каталогом, куда следует поместить извлеченные файлы. Опции команды позволяют указать ветвь, в которую будет извлекаться код, и управлять сохранением временного каталога.

8.6. Изменение задания

Команда devtool modify служит для изменения источников имеющегося задания. Она похожа на команду add, но не создает нового задания на уровне workspace, поскольку задание уже присутствует в другом уровне. Команда извлекает файлы исходного кода, организуя их в локальный репозиторий Git, если источник еще не был получен из Git, выбирает ветвь для разработки и применяет все правки, зафиксированные (commit) в задании. При вводе команды devtool modify recipe программа devtool будет использовать оператор SRC_URI в имеющемся задании для указания восходящего источника и извлечет исходные файлы в заданное по умолчанию место, используя по умолчанию ветвь devtool.

8.7. Редактирование задания

Команда devtool edit-recipe запускает редактор, указанный в переменной EDITOR внутри файла задания. В команде нужно указывать корневое имя задания (без версии и расширения), а файл задания должен размещаться в структуре workspace. Однако эти требования можно переопределить с помощью опции -a или –any-recipe.

8.8. Обновление задания

Команда devtool update-recipe служит для обновления задания правками (patch), отражающими изменения в исходных файлах. Например, при намерении работать с тем или иным кодом можно сначала использовать команду devtool modify для извлечения кода и организации рабочего пространства. Затем можно изменить, скомпилировать и протестировать код. Когда результат будет достигнут и изменения зафиксированы (commit) в репозитории Git, можно воспользоваться командой devtool update-recipe для создания patch-файлов и обновления задания.

$ devtool update-recipe recipe

Команда devtool update-recipe будет игнорировать незафиксированные изменения.

Зачастую программные настройки будут меняться в пользовательском уровне а не в исходном задании. В таких случаях можно использовать опцию -a или --append в команде devtool update-recipe,позволяющую указать уровень.

$ devtool update-recipe recipe -a base-layer-directory

При этом создается файл дополнения *.bbappend в нужном каталоге указанного уровня, который может (не обязательно) быть включен в файл bblayers.conf. Если файл дополнения уже имеется, команда обновит его.

8.9. Проверка статуса обновления задания

Восходящие задания время от времени меняются, поэтому может возникнуть потребность в их обновлении. Для проверки статуса задания служит команда devtool check-upgrade-status,которая выводит таблицу текущих версий заданий, последних версий этих заданий, адреса электронной почты сопровождающих и другую информацию, такую как хэш-значения фиксаций и возможные причины обновления. Для уровняoe-core адреса сопровождающих берутся из файла maintainers.inc. Если задание использует сборщик Git fetcher, а не архив, хэш фиксации указывается для тега последней версии.

Как для всех команд devtool можно получить справку

     $ devtool check-upgrade-status -h
     NOTE: Starting bitbake server...
     usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]]

     Prints a table of recipes together with versions currently provided by
     recipes, and latest upstream versions, when there is a later version available

     arguments:
       recipe      Name of the recipe to report (omit to report upgrade info for
                   all recipes)

     options:
      -h, --help  show this help message and exit
       --all, -a   Show all recipes, not just recipes needing upgrade

Если в команде не указано конкретное задание, проверяться будут все заданий для всех уровней в конфигурации. Ниже приведена часть выходной таблицы для всех заданий. Отметим, что в списке указана причина не обновлять задание base-passwd,связанная с тем, что для этого требуется обновить такжеcdebconf,что достаточно сложно. Когда причина отказа от обновления указана, она обычно записывается в файл задания (RECIPE_NO_UPDATE_REASON). Пример можно найти в файлеbase-passwd.bb.

     $ devtool check-upgrade-status
         ...
         NOTE: acpid                     2.0.30          2.0.31
     Ross Burton <ross.burton@intel.com>
         NOTE: u-boot-fw-utils           2018.11         2019.01
     Marek Vasut <marek.vasut@gmail.com>
     d3689267f92c5956e09cc7d1baa4700141662bff
         NOTE: u-boot-tools              2018.11         2019.01
     Marek Vasut <marek.vasut@gmail.com>
     d3689267f92c5956e09cc7d1baa4700141662bff
          ...
         NOTE: base-passwd               3.5.29          3.5.45
     Anuj Mittal <anuj.mittal@intel.com>  cannot be updated due to: Version
     3.5.38 requires cdebconf for update-passwd utility
         NOTE: busybox                   1.29.2          1.30.0
     Andrej Valek <andrej.valek@siemens.com>
         NOTE: dbus-test                 1.12.10         1.12.12
     Chen Qi <Qi.Chen@windriver.com>

8.10. Обновление задания

По мере развития программ задания обновляются с новыми версиями. Разработчику следует поддерживать актуальность своих локальных заданий, для чего имеется несколько методов, описанных в разделе Upgrading Recipes [2]. Здесь описано обновление с помощью команды devtool upgrade. Перед обновлением задания следует проверить его статус, как описано в параграфе 8.9. Проверка статуса обновления задания.

Команда devtool upgrade обновляет имеющееся задание до последней версии восходящего источника. Файл обновленного задания и связанные с ним файлы помещаются в workspace и при необходимости распаковываются в указанное место дерева источников. В процессе обновления связанные с заданием patch-файлы также обновляются или добавляются.

При использовании команды devtool upgrade нужно указывать базовое имя задания (без версии, пути и расширения), а также каталог, в который нужно извлечь исходный код. Опции команды позволяют управлять номером версии для обновления (PV), выпуском (SRCREV), применением patch-файлов и т. п.

Дополнительную информацию о работе с devtoolможно найти в разделеUse devtool upgrade to Create a Version of the Recipe that Supports a Newer Version of the Software [7], а примеры использования devtool upgrade – в Using devtool upgrade [2].

8.11. Сброс задания

Команда devtool reset удаляет задание и его конфигурацию (например, файл .bbappend) с уровня workspace. Следует понимать, что команда не переносит файлов задания, поэтому нужно поместить завершенное задание и файл дополнения в нужное место за пределами workspace перед использованием команды devtool reset. Если команда devtool reset обнаруживает, что файл задания или дополнения был изменен, эти измененные файлы сохраняются в каталоге attic на уровне workspace. Ниже приведен пример сброса каталога workspace, содержащего задание mtr.

$ devtool reset mtr
NOTE: Cleaning sysroot for recipe mtr...
NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no
  longer need it then please delete it manually

8.12. Сборка задания

Команда devtool build служит для сборки заданий и эквивалентна команде bitbake -c populate_sysroot. При использовании команды нужно указывать базовое имя задания (без версии, пути и расширения). Опция -s или –disable-parallel-make позволяет отключить при сборке параллельные операции.

8.13. Сборка образа

Команда devtool build-image служит для сборки образа со включением в него пакетов из workspace. Команда удобна для создания образов в процессе тестирования приложений. Для окончательной установки пакета в образ следует отредактировать задание для образа. Команда требует указать образ, куда включаются пакеты и имеет вид

$ devtool build-image image

8.14. Развертывание программ на целевой машине

Команда devtool deploy-target служит для развертывания вывода сборки «вживую» на целевой машине.

$ devtool deploy-target recipe target

Цель указывается адресом или именем и должна поддерживать сервер SSH (user@hostname[:destdir]).

Команда размещает все файлы, установленные задачей do_install. На целевой платформе не требуется менеджер пакетов, а при наличии он обходится. Команда deploy-target предназначена лишь для разработки и ее не следует применять для создания окончательного образа.

Поведение развернутых приложений в некоторых случаях может оказаться неожиданным, если развертывается новое приложение, задание для сборки которого учитывает все рабочие зависимости, на целевой платформе нет пакетов, от которых приложение зависит. Некорректное поведение объясняется тем, что команда devtool deploy-target не развертывает пакеты (например, библиотеки), от которых зависит новое приложение. Поэтому при вызове новым приложением отсутствующей функции результаты могут быть неожиданными. Для предотвращения подобных проблем следует заранее установить все нужные пакеты на целевой платформе.

8.15. Удаление программ с целевой машины

Команда devtool undeploy-target позволяет удалить развернутый на целевой машине вывод сборки, перенесенный туда ранее командой devtool deploy-target. Цель указывается адресом или именем и должна поддерживать сервер SSH (user@hostname[:destdir]).

$ devtool undeploy-target recipe target

8.16. Создание уровня рабочего пространства в другом месте

Команда devtool create-workspace создает новый уровень workspace в каталоге сборки, в котором создается файл README и каталог conf. Приведенная ниже команда создает уровень workspace в текущем рабочем уровне.

     $ devtool create-workspace

Можно создать уровень workspace в другом месте, а также изменить его имя, например devtool create-workspace /home/scottrif/new-workspace, создаст уровень new-workspace в домашнем каталоге пользователя scottrif.

8.17. Получение статуса заданий в рабочем пространстве

Команда devtool status выводит список заданий, размещенных на уровне workspace, включая пути к соответствующим внешним деревьям кода. Приведенная ниже команда показывает задание mtr_0.86.bb и путь к его файлам.

$ devtool status
mtr: /home/scottrif/poky/build/workspace/sources/mtr
     (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)

8.18. Поиск доступных заданий для целей

Команда devtool search позволяет найти доступные задания для цели по имени задания или пакета, а также по описанию и установленным файлам.

Глава 9. Справочник по OpenEmbedded Kickstart (`.wks`)

9.1. Введение

Текущая реализация Wic поддерживает только базовые команды kickstart для разделов – partition (сокращенно part) и bootloader. В новых версиях будут добавлены другие команды и опции. Использование неподдерживаемых команд ведет к непредсказуемым результатам.

В этой главе описаны доступные команды kickstart, их синтаксис и опции. Команды основаны на версиях Fedora kickstart с изменениями, учитывающими возможности Wic. Полная документация по командам доступна по ссылке.

9.2. Команда part (partition)

Каждая из этих команд создает в системе раздел, используя приведенный ниже синтаксис.

part [mntpoint] 
partition [mntpoint]

Если точка монтирования mntpoint не указана, Wic создает раздел, не монтируя его. Параметр mntpoint должен принимать одну из двух форм:

/path – например, “/”, “/usr”, “/home”;
swap – раздел, используемый для подкачки (swap).

Указание mntpoint приводит к автоматическому монтированию раздела. Wic обеспечивает это путем добавления записей в таблицу файловых систем (fstab) при генерации образа. Для генерации Wic корректного файла fstab нужно указать также опцию раздела –ondrive, –ondisk или –use-uuid partition как часть команды.

Программа mount должна понимать синтаксис PARTUUID, используемый с –use-uuid и не корневыми точками монтирования, включая swap. Версии этой команды в busybox в настоящее время не умеют этого.

Ниже приведен пример с точкой монтирования /. Опция –ondisk служит для указания раздела на диске sdb.

     part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024

Ниже приведен список поддерживаемых командой part (partition) опций.

–size задает минимальный размер раздела в мегабайтах целым числом без суффикса MB. Опция нужна при использовании –source.
–fixed-size задает точный размер раздела в мегабайтах и не может использоваться вместе с –size. Если собранный образ больше заданного опцией размера, возникает ошибка.
–source является опцией Wic, которая задает источник данных для заполнения раздела. Чаще всего эта опция имеет значение rootfs, но могут применяться и другие значения, отображаемые на пригодный подключаемый модуль (source plug-in, см. раздел Using the Wic Plug-Ins Interface [2]).
При использовании –source rootfs Wic создает раздел требуемого размера и заполняет его содержимым корневой файловой системы, указанным опцией -r или эквивалентом rootfs, полученным из опции -e. Тип файловой системы для создания раздела выводится из опции –fstype.

При задании –source plugin-name Wic создает раздел требуемого размера и заполняет его содержимым, которое создается заданным подключаемым модулем с использованием данных, указанных опцией -r или эквивалентом rootfs, полученным из опции -e. Содержимое и тип файловой системы зависят от плагина.

Если опция –source не применяется, команда wic создает пустой раздел, поэтому нужна опция –size для точного задания размера.
--ondisk или --ondrive задает создание раздела на определенном диске.
--fstype задает тип файловой системы для раздела (ext4, ext3, ext2, btrfs, squashfs, swap).
--fsoptions задает строку опций в произвольной форме для использования при монтировании файловой системы. Строка копируется в файл /etc/fstab установленной системы и заключается в кавычки. Если опция не задана, используется значение defaults.
–label label задает метку файловой системы (label) для раздела. Если такая метка уже применяется другой файловой системой, создается новая метка.
--active помечает раздел как активный (загрузка).
–align (кбайт) – специальная опция Wic, указывающая начало раздела на границе, кратной заданному числу.
--no-table – специальная опция Wic, резервирующая пространство для раздела без добавления записи в таблицу разделов.
--exclude-path – специальная опция Wic, исключающая указанный путь из результирующего образа. Работает только с плагином rootfs.
--extra-space – специальная опция Wic, добавляющая пространство (по умолчанию 10 Мбайт) к занятому разделом месту. Окончательный размер раздела превышает заданный параметром --size.
--overhead-factor – специальная опция Wic, умножающая размер раздела на значение опции, которое должно быть больше 1 (по умолчанию 1.3).
--part-name – специальная опция Wic, задающая имя раздела GPT.
--part-type – специальная опция Wic, задающая тип идентификатора GUID для раздела GPT. Список типов GUID можно найти на странице http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs.
--use-uuid – специальная опция Wic, заставляющая Wic генерировать случайный идентификатор GUID для раздела, используемый в конфигурации загрузчика для указания корневого раздела.
--uuid – специальная опция Wic, задающая UUID для раздела.
--fsuuid – специальная опция Wic, задающая UUID файловой системы. Можно генерировать или обновлять WKS_FILE с помощью этой опции, если заранее заданный идентификатор UUID добавлен в команду загрузки ядра в конфигурационном файле загрузчика перед запуском Wic.
--system-id – специальная опция Wic, задающая системный идентификатор раздела (1-битовое шестнадцатеричное значение с необязательным префиксом 0x.
–mkfs-extraopts задает опции для передачи утилите mkfs, в дополнение к принятым по умолчанию опциям, которые на некоторых файловых системах могут не работать. Доступные опции можно увидеть по команде wic
help kickstart.

9.3. Команда bootloader

Эта команда управляет конфигурацией загрузчика с помощью описанных ниже параметров. Функциональность загрузчика и загрузочные разделы реализуются подключаемыми модулями (–source).
Команда bootloader по сути обеспечивает способ изменения конфигурации загрузчика.

–timeout задает время ожидания (секунды) загрузчика перед выбором заданного по умолчанию варианта.
–append задает параметры ядра, добавляемые к команде syslinux APPEND или grub.
–configfile указывает пользовательский файл конфигурации для загрузчика. Если файл не находится в каталоге canned-wks, нужно указать полный путь. Этот файл переопределяет все опции загрузчика.

Глава 10. Ошибки и предупреждения тестов QA

10.1. Введение

При сборке задания система OE выполняет разные проверки QA, выдавая предупреждения и ошибки. Иногда новое задание для сборки программ не создает проблем, однако зачастую они возникают и приходится вносить изменения.

Хотя соблазнительно не обращать внимания на сообщения QA или даже отключить проверки, лучше попытаться решить обнаруженные при проверке проблемы. Эта глава посвящена сообщениям QA и содержит краткие рекомендации по устранению проблем.

В следующем параграфе представлены все сообщения QA в принятой по умолчанию конфигурации. Каждая запись содержит текст сообщения и комментарии.

В конце каждого сообщения указан связанный с ним тест QA (как указано в параграфе 6.56. insane.bbclass).
Список ошибок и предупреждений относится лишь к тестам QA и не включает другие возможные ошибки.
Поскольку некоторые тесты QA по умолчанию отключены, они не учтены здесь.

10.2. Ошибки и предупреждения

<packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]

Указанный пакет содержит файлы в /usr/libexec, тогда как конфигурация дистрибутива указывает другой путь к <libexecdir> (по умолчанию $prefix/libexec, но может быть измене, например, ${libdir}).

package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]

Указанный двоичный файл, созданный заданием, содержит пути загрузки динамических библиотек (rpaths) с путями сборки (такими как TMPDIR), которые некорректны для цели и могут создавать проблемы безопасности. Следует проверить опции -rpath, передаваемые компоновщику, в журнале задачи do_compile. В зависимости от используемой системы сборки, могут быть опции для полного запрета использования rpath при сборке задания.

<packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]

Указанный двоичный файл, созданный заданием, содержит пути загрузки динамических библиотек (rpaths), которые на стандартных системах просматриваются компоновщиком по умолчанию (например, /lib и /usr/lib). Такие пути не вызывают неполадок, но занимают место, будучи ненужными. В зависимости от используемой системы сборки, могут быть опции для полного запрета использования rpath при сборке задания.

<packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]

В указанных файлах пакета <packagename> были обнаружены зависимости на уровне файлов, не соответствующие явно записям в RDEPENDS. Если файлы нужны при работе, RDEPENDS в задании следует указывать пакеты, предоставляющие эти файлы.

<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]

Между указанными пакетами имеется зависимость при работе, но в задании ничто явно не указывает системе сборки OE необходимость выполнения этой зависимости. Это обычно связано с добавлением значения RDEPENDS на этапе подготовки пакета вместо того, чтобы автоматически сделать это раньше на основе содержимого пакета. В большинстве случаев в задание следует явно добавить RDEPENDS для зависимости.

non-dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]

Символьные ссылки на файлы .so, предназначенные лишь для разработки, которые нужно перенести в пакет -dev. Это может возникать при добавлении *.so* вместо *.so.* в пакеты, не относящиеся к разработке. Следует изменить FILES (возможно и PACKAGES), чтобы указанные файлы .so перешли в пакет -dev.

non-staticdev package contains static .a library: <packagename> path '<path>' [staticdev]

Файлам статической библиотеки .a следует быть в пакете -staticdev. Следует изменить FILES (возможно и PACKAGES), чтобы указанные файлы .a перешли в пакет -staticdev.

<packagename>: found library in wrong location [libdir]

Указанный файл может быть установлен в некорректно (возможно заданное жестко) место. Например, проверка будет указывать задания, которые устанавливают файлы /lib/bar.so, когда ${base_libdir} = “lib32”. Другим случаем является установка заданием /usr/lib64/foo.so при ${libdir} = “/usr/lib”. Возможны ложные срабатывания и в таких случаях следует добавить “libdir” в INSANE_SKIP для пакета.

non debug package contains .debug directory: <packagename> path <path> [debug-files]

Указанный пакет содержит каталог .debug, которому не следует появляться вне пакетов -dbg. Это может быть связано с добавлением пути, содержащего каталог .debug, и неявным добавлением .debug в пакет -dbg. В таких случаях следует явно добавить .debug в переменную FILES_${PN}-dbg.

Architecture did not match (<machine_arch> to <file_arch>) on <file> [arch]

По умолчанию система сборки OE проверяет тип ELF, размер слова и порядок битов во всех двоичных файлах на предмет соответствия целевой архитектуре. Отрицательный результат проверки может говорить о выборе неверного компилятора или опций. Иногда для программ (например, загрузчиков) требуется обход этого теста. Если файл, для которого указываются ошибки, относится к микрокоду, не предназначенному для выполнения в целевой операционной системе, следует добавить arch в переменную INSANE_SKIP для пакета. Помощь в обнаружении источника проблем может оказать просмотр журнала задачи do_compile в части неверных опций.

Bit size did not match (<machine_bits> to <file_bits>) <recipe> on <file> [arch]

Endianness did not match (<machine_endianness> to <file_endianness>) on <file> [arch]

ELF binary '<file>' has relocations in .text [textrel]

Указанный двоичный файл ELF содержит перемещения (relocation) в своих разделах .text. Это влияет на производительность работы. Обычно проблему можно решить добавлением опции компилятора -fPIC или -fpic. Например, для программы, читающей при сборке переменную CFLAGS можно добавить в задание строку CFLAGS_append = ” -fPIC “. Дополнительная информация о перемещениях в процессе работы доступна по ссылке.

No GNU_HASH in the elf binary: '<file>' [ldflags]

Двоичный файл, созданный при сборке задания не был скомпонован с опциями LDFLAGS, предоставленными системой сборки. Следует проверить передачу переменной LDFLAGS команде компоновщика. Для обхода проблемы в этой ситуации обычно применяется передача LDFLAGS с помощью TARGET_CC_ARCH внутри задания в форме TARGET_CC_ARCH += “${LDFLAGS}”.

Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]

Указанный пакет содержит драйвер Xorg, но не имеет соответствующей зависимости ABI. Имена драйверов ABI предоставляет пакет xserver-xorg и все драйверы должны зависеть от версии ABI, с которой они были собраны. Задания для драйверов, включающие xorg-driver-input.inc или xorg-driver-video.inc получают эту версию автоматически, поэтому следует лишь явно добавить зависимости в задания для двоичных драйверов.

The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]

Каталог /usr/share/info/dir не следует включать в пакеты. Для этого следует добавить в задачу do_install или do_install_append строку rm ${D}${infodir}/dir.

Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]

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

<file> failed sanity test (workdir) in path <path> [la]

Указанный файл .la содержит пути TMPDIR. Это некорректно, поскольку libtool добавляет префикс sysroot при использовании файлов.

<file> failed sanity test (tmpdir) in path <path> [pkgconfig]

Указанный файл .pc содержит пути TMPDIR/WORKDIR. Это некорректно, поскольку pkg-config добавляет префикс sysroot при доступе к файлам.

<packagename> rdepends on <debug_packagename> [debug-deps]

Имеется зависимость между указанным пакетом, не относящимся к отладке (имя пакета не имеет суффикса -dbg), и пакетом dbg. Пакеты dbg содержат отладочные символы и могут создаваться несколькими способами:

включение dbg-pkgs в IMAGE_FEATURES;
использование IMAGE_INSTALL;
как зависимость другого пакета dbg, созданного одним из предыдущих способов.

Зависимости могут добавляться автоматически в результате ошибочного включения ненужных фалов в пакет dbg (например, файл .so вместо символьной ссылки) или вручную (например, через переменную RDEPENDS).

<packagename> rdepends on <dev_packagename> [dev-deps]

Имеется зависимость между указанным пакетом, не относящимся к разработке (имя пакета не имеет суффикса -dev), и пакетом для разработки. Пакеты dev включают файлы заголовков и могут создаваться разными способами:

включение dev-pkgs в IMAGE_FEATURES;
использование IMAGE_INSTALL;
как зависимость другого пакета dev,созданного одним из предыдущих способов.

Зависимости могут добавляться автоматически в результате ошибочного включения ненужных фалов в пакет dev (например, файл .so вместо символьной ссылки) или вручную (например, через переменную RDEPENDS).

<var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]

При добавлении зависимости с учетом версии в одну из переменных RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RREPLACES, RCONFLICTSдолжны применяться лишь указанные операторы сравнения. Следует изменить значения зависимостей с учетом версий в соответствии с сообщением.

<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]

Журнал задачи do_compile показывает, что файлы отыскивались по путям на хосте – это неприемлемо для кросс-компиляции. Следует найти эти имена по строке «is unsafe for cross-compilation» или «CROSS COMPILE Badness».

<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]

Журнал задачи do_install показывает, что файлы отыскивались по путям на хосте – это неприемлемо для кросс-компиляции. Следует найти эти имена по строке «is unsafe for cross-compilation» или «CROSS COMPILE Badness».

This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'

Журнал задачи do_configure показывает, что файлы отыскивались по путям на хосте – это неприемлемо для кросс-компиляции. Следует найти эти имена по строке «is unsafe for cross-compilation» или «CROSS COMPILE Badness».

<packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]

Внутреннее соглашение системы сборки OE (иногда вынуждаемое менеджером пакетов) требует указывать имена пакетов в нижнем регистре. Если задание не следует этому или добавляются пакеты, не соответствующие соглашению, в переменную PACKAGES,выдается данное сообщение. В таких случаях следует переименовать задание или имена пакетов, включенных вPACKAGES.

<recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]

Сценарий configure сообщает о непонятной опции, что может быть следствием изменения набора поддерживаемых параметров или возникновения ошибки в имени опции. Следует внимательно посмотреть вывод команды ./configure --help и журнал изменений в репозитории (change log), а затем должным образом изменить переменные EXTRA_OECONF, PACKAGECONFIG_CONFARGSили отдельные опции вPACKAGECONFIG.

Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]

Имя указанного задания (PN) присутствует в OVERRIDES. Если задание названо так, что его имя соответствует чему-либо включенному в OVERRIDES (например, PN совпадает с MACHINE или DISTRO), могут возникать неожиданные последствия. Например, назначение вида FILES_${PN} = "xyz" будет приводить к FILES = "xyz". Следует переименовать задание (или PN,если переменная задана явно) для устранения конфликта.

<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]

Некоторые переменные (RDEPENDS, RRECOMMENDS, RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES, FILES, pkg_preinst, pkg_postinst, pkg_prerm, pkg_postrm, ALLOW_EMPTY) всегда следует устанавливать для конкретного пакета (т. е. использовать переопределением вида RDEPENDS_${PN} = "value", а не RDEPENDS = "value"). Следует исправить назначение переменных в задании.

File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]

Из созданных двоичных файлов уже вырезаны отладочные символы перед тем, как система сборки попыталась их извлечь. В разрабатываемых проектах часто вырезают отладочные символы по умолчанию. Для отладки пакетов на целевой платформе с использованием пакетов -dbg удаление символов должно быть отключено. В некоторых системах сборки это можно отключить указанием в конфигурации дополнительной опции. В иных случаях может потребоваться исправление сценариев сборки. Для этого следует насти в команде компоновки строки strip или STRIP и опции -s или -S (возможна их передача из командной строки компилятора через опцию -Wl). Запрет вырезания символов не означает их наличия в двоичных пакетах, поскольку система сборки OE выделяет эти символы в пакеты -dbg, вырезая из двоичных файлов.

<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]

Имя пакета должно указываться в переменной PACKAGES лишь 1 раз. Следует проверить переменную.

FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]

Строка // некорректна в пути Unix. Следует найти ее в переменной FILES и заменить на /.

<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]

Файлы установлены задачей do_install, но не включены в переменную FILES какого-либо задания. Такие файлы не могут пристутствовать в образе на последующих этапах сборки, поэтому нужно добавить их в переменную FILES соответствующего пакета (например, FILES_${PN} для основного пакета) или удалить файлы в конце задачи do_install, если они не нужны.

<oldpackage>-<oldpkgversion> was registered as shlib provider for <library>, changing it to <newpackage>-<newpkgversion> because it was built later

Указанную общую библиотеку предоставляют сразу <oldpackage> и <newpackage>. Это может быть следствием смены имени задания. Однако в иных случаях сообщение может означать, что ошибочно провайдером указана «приватная» версия библиотеки вместо общей. Тогда следует добавить файл библиотеки .so в переменную PRIVATE_LIBS задания, обеспечивающего приватную версию библиотеки.

10.3. Настройка и отключение проверок QA

Можно настроить проверки QA глобально, чтобы отказ конкретной проверки вызывал ошибку или предупреждение, с помощью переменных WARN_QA и ERROR_QA. Можно также отключить проверки в конкретном задании, используя INSANE_SKIP. Информация о проверках QA приведена в параграфе 6.56. insane.bbclass.

Следует помнить, что проверки QA предназначены для обнаружения имеющихся и возможных проблем в выводе пакетов, поэтому следует отключать эти проверки с осторожностью.

Глава 11. Образы

Система сборки OE включает несколько образов для разных случаев, имена которых можно указать в команде bitbake для сборки.

Сборка образов без компонент с лицензиями GPLv3, LGPLv3 или AGPL-3.0 поддерживается только для минимальных и базовых вариантов. Кроме того, для образов с компонентами, использующими лицензию, отличную от GPLv3 и подобных ей, нужно внести соответствующие изменения в файл local.conf до ввода команды BitBake для сборки.

Поместить символ комментария в начало строки EXTRA_IMAGE_FEATURES.
Установить INCOMPATIBLE_LICENSE = “GPL-3.0 LGPL-3.0 AGPL-3.0”.

Посмотреть образы в в локальном репозитории poky Git можно с помощью команды ls meta*/recipes*/images/*.bb. Список поддерживаемых заданий приведен ниже.

build-appliance-image

Пример виртуальной машины, содержащей все компоненты, требуемые для запуска сборки, использующей систему сборки, а также самой системы сборки. Можно собрать и запустить образ с помощью VMware Player или VMware Workstation. Дополнительная информация приведена на странице Build Appliance сайта YP.

core-image-base

Образ с консольным интерфейсом и полной поддержкой оборудования целевой платформы.

core-image-clutter

Образ с поддержкой инструментов Clutter на основе Open GL, обеспечивающих разработку графических интерфейсов с анимацией.

core-image-full-cmdline

Образ с консольным интерфейсом и расширенной функциональностью Linux.

core-image-lsb

Образ, соответствующий спецификации LSB, требующий конфигурации дистрибутива в соответствии с LSB (например, poky-lsb). При сборке core-image-lsb без такой конфигурации образ не будет соответствовать LSB.

core-image-lsb-dev

Образ core-image-lsb с поддержкой разработки на хосте, включающий файлы заголовков и библиотеки, нужные для разработки. Образ требует конфигурации дистрибутива в соответствии с LSB (например, poky-lsb). При сборке core-image-lsb-dev без такой конфигурации образ не будет соответствовать LSB.

core-image-lsb-sdk

Образ core-image-lsb с поддержкой кросс-разработки, включающий файлы заголовков и библиотеки, нужные для формирования автономного SDK. Образ требует конфигурации дистрибутива в соответствии с LSB (например, poky-lsb). При сборке core-image-lsb-sdk без такой конфигурации образ не будет соответствовать LSB. Образ пригоден для разработки на целевой платформе.

core-image-minimal

Компактный образ, пригодный для загрузки на устройстве.

core-image-minimal-dev

Образ core-image-minimal с поддержкой разработки на хосте, включающий файлы заголовков и библиотеки, нужные для разработки.

core-image-minimal-initramfs

Образ core-image-minimal с файловой системой initramfs как частью ядра, которая позволяет более эффективно находить первую программу init (см. описание переменной PACKAGE_INSTALL).

core-image-minimal-mtdutils

Образ core-image-minimal с поддержкой утилит Minimal MTD, позволяющий пользователю взаимодействовать с подсистемой MTD в ядре для операций с flash-устройствами.

core-image-rt

Образ core-image-minimal с набором тестов и инструментов для работы в реальном масштабе времени.

core-image-rt-sdk

Образ core-image-rt с кросс-инструментами, заголовочными файлами и библиотеками для создания автономного SDK, пригодного для разработки на целевой платформе.

core-image-sato

Образ с поддержкой среды Sato для мобильных устройств. Образ поддерживает X11 с темой Sato, термина, редактор, менеджер файлов, проигрыватель и т. п.

core-image-sato-dev

Образ core-image-sato для разработки на хосте. Включает библиотеки для сборки приложений на устройстве, инструменты тестирования и профилирования, отладочные символы (прежнее название core-image-sdk).

core-image-sato-sdk

Образ core-image-sato с включением кросс-инструментов. Включает файлы заголовков и библиотеки для формирования автономного SDK, поддерживающего разработку на целевой платформе.

core-image-testmaster

базовый образ для автоматизированного тестирования, разворачиваемый на своем разделе, что позволяет развернуть тестируемый образ отдельно. Подробно описан в разделе Performing Automated Runtime Testing [2].

core-image-testmaster-initramfs

Образ initramfs, адаптированный для использования с core-image-testmaster.

core-image-weston

Простой образ Wayland с терминалом, включающий терминальные библиотеки и эталонный сборщик Weston (см. раздел Using Wayland and Weston [2]).

core-image-x11

Базовый образ X11 с терминалом.

Глава 12. Свойства

В этой главе описаны свойства машин и дистрибутивов, которые можно включить в образ, и описаны свойства образов. Свойства позволяют определить пакеты, включаемые в создаваемый образ. Дистрибутив позволяет выбрать включаемые свойства через переменную DISTRO_FEATURES, которая задается или дополняется в конфигурационном файле дистрибутива (poky.conf, poky-tiny.conf, poky-lsb.conf и т. п.). Свойства машины задаются в переменной MACHINE_FEATURES, устанавливаемой в файле конфигурации машины и задающей аппаратные возможности. Эти две переменные определяют модули ядра, утилиты и другие пакеты для включения в образ. Дистрибутив позволяет задать набор свойств машины, которые не будут включаться, если дистрибутив их не поддерживает.

Одним из методов определения заданий, которые проверяются на предмет определенного свойства, является просмотр метаданных для свойства. Ниже приведен пример поиска заданий, сборка которых может быть изменена с учетом указанного свойства.

$ cd poky
     $ git grep 'contains.*MACHINE_FEATURES.*feature'

12.1. Свойства машины

Ниже перечислены элементы, которые можно указать в MACHINE_FEATURES. Свойства не соответствуют однозначно пакетам и могут выходить за рамки простого управления пакетами. Иногда свойство может влиять на сборку нескольких заданий. Например, свойство может указывать наличие некого параметра задачи do_configure в задании. В списке свойств представлены только свойства из метаданных YP.

acpi – оборудование включает ACPI (x86/x86_64).
alsa – оборудование имеет драйверы ALSA.
apm – оборудования использует APM (или эмуляцию APM).
bluetooth – оборудование имеет встроенные элементы BT.
efi – поддержка загрузки через EFI.
ext2 – устройство HDD или Microdrive.
irda – оборудование поддерживает IrDA.
keyboard – устройство имеет клавиатуру.
pcbios – поддержка загрузки через BIOS.
pci – оборудование имеет шину PCI.
Pcmcia – оборудование имеет гнезда PCMCIA или CompactFlash.
phone – поддержка мобильных телефонов (голос).
qvga – машина имеет дисплей QVGA (320×240).
rtc – машина имеет часы RTC.
screen – устройство имеет экран.
serial – устройство имеет последовательный порт (обычно RS232).
touchscreen – устройство имеет сенсорный экран.
usbgadget – оборудование поддерживает устройства USB (гаджеты).
usbhost – оборудование поддерживает хост USB.
vfat – поддержка файловой системы FAT.
wifi – оборудование имеет встроенные элементы WiFi.

12.2. Свойства дистрибутива

Ниже представлен список свойств, которые можно установить для дистрибутива в переменной DISTRO_FEATURES.Свойства не соответствуют однозначно пакетам и могут выходить за рамки простого управления пакетами. Иногда свойство может влиять на сборку нескольких заданий. Например, свойство может указывать наличие некого параметра задачиdo_configureв задании.

Некоторые свойства дистрибутива являются и свойствами машины. Управлять такими свойствами можно на обоих уровнях (см. описание переменной COMBINED_FEATURES). В списке представлены лишь свойства из метаданных YP.

alsa – включает поддержку ALSA (при доступности устанавливаются модули ядра для совместимости с OSS).
api-documentation – включает создание документации API при сборке. Документация добавляется в архив SDK при использовании команды bitbake -c populate_sdk (раздел Adding API Documentation to the Standard SDK [7]).
bluetooth – включает поддержку bluetooth (только встроенные BT).
bluez5 – включает BlueZ версии 5 с поддержкой базовых уровней и протоколов Bluetooth. По умолчанию значение DISTRO_FEATURES включает bluetooth, что вызывает включение bluez5. Если поддержка bluez5 не нужна и достаточно bluez4, нужно задать DISTRO_FEATURES_BACKFILL_CONSIDERED = “bluez5”. Установка этой переменной говорит системе сборки OE, что использование bluez5 исключается в пользу bluez4.
cramfs – включает поддержку CramFS.
directfb – включает поддержку DirectFB.
ext2 – включает инструменты для поддержки устройств с HDD/Microdrive для хранения файлов.
ipsec – включает поддержку IPSec.
ipv6 – включает поддержку IPv6.
irda – включает поддержку IrDA.
keyboard – включает поддержку клавиатуры (например, будет загружаться keymap).
ldconfig – включает поддержку ldconfig и ld.so.conf на целевой платформе.
nfs – включает поддержку клиентов NFS (для монтирования на устройстве NFS export).
opengl – включает библиотеку Open GL, обеспечивающую кроссплатформенный и многоязычный интерфейс API для плоской и трехмерной графики.
pci – включает поддержку шины PCI.
pcmcia – включает поддержку PCMCIA/CompactFlash.
ppp – включает поддержку PPP dialup.
ptest – включает сборку тестов пакетов для отдельных заданий (см. Testing Packages With ptest [2]).
smbfs – включает поддержку клиентов SMB (для монтирования каталогов Samba/Microsoft Windows).
systemd – включает поддержку менеджера инициализации systemd, который является полной заменой init и обеспечивает параллельный запуск служб, снижение нагрузки на оболочку и пр.
usbgadget – включает поддержку USB Gadget (для разных устройств USB).
usbhost – включает поддержку USB Host (подключение внешней клавиатуры, мыши, дисков и т. п.).
wayland — включает серверный протокол Wayland и библиотеку для его поддержки.
wifi – включает поддержку встроенных устройств WiFi.
x11 – включает X-сервер и библиотеки поддержки.

12.3. Свойства образа

Содержимым образов, создаваемых системой сборки OE, можно управлять с помощью переменных IMAGE_FEATURES и EXTRA_IMAGE_FEATURES,которые обычно указываются в задании для образа. Эти переменные помогают выбрать возможности из предопределенных вариантов, такие как отладка или средства разработки.

Ниже пеерчислены свойства (возможности) доступные для всех образов.

allow-empty-password позволяет входить в Dropbear и OpenSSH с именем root и другими именами без пароля.
dbg-pkgs устанавливает отладочные символы для всех пакетов, включенных в образ.
debug-tweaks делает образ пригодным для отладки (см. свойства allow-empty-password, empty-root-password, post-install-logging).
dev-pkgs устанавливает компоненты разработки (заголовочные файлы и дополнительные библиотеки) для всех пакетов в образе.
doc-pkgs устанавливает пакеты документации для всех пакетов в образе.
empty-root-password устанавливает пустой пароль для пользователя root.
package-management устанавливает средства управления пакетами и сохраняет базу данных о пакетах.
post-install-logging включает запись событий пост-установочных сценариев в файл /var/log/postinstall.log при первой загрузке образа на целевой системе. Переменная VOLATILE_LOG_DIR = no делает каталог /var/log в образе постоянным.
ptest-pkgs устанавливает пакеты ptest для всех поддерживающих ptest пакетов.
read-only-rootfs создает образ с корневой файловой системой, доступной лишь для чтения (см. раздел Creating a Read-Only Root Filesystem [2]).
splash включает вывод заставки в процессе загрузки системы. По умолчанию заставка обеспечивается пакетом psplash, который не позволяет менять свою конфигурацию. Можно использовать другую заставку, указав имя пакета (пакетов) в переменной SPLASH задания для образа или на уровне конфигурации дистрибутива.
staticdev-pkgs устанавливает статические библиотеки разработки (файлы *.a) для всех пакетов в образе.

Некоторые образы, доступные лишь при наследовании класса core-image,перечислены ниже.

hwcodecs устанавливает кодеки аппаратного ускорения.
nfs-server устанавливает сервер NFS.
perf устанавливает инструменты профилирования, такие как perf, systemtapиLTTng. Информация о работе с этими инструментами приведена в [7].
ssh-server-dropbear устанавливает Dropbear (минимальный сервер SSH).
ssh-server-openssh устанавливает сервер OpenSSH SSH с более развитыми функциями, нежели Dropbear. При наличии обоих серверов OpenSSH и Dropbear в переменной IMAGE_FEATURESпредпочтение будет отданоOpenSSH и Dropbear не будет устанавливаться.
tools-debug устанавливает средства отладки, такие как strace и gdb. Информация о работе с GDB приведена в разделе Debugging With the GNU Project Debugger (GDB) Remotely [2], а трассировка описана в [9].
tools-sdk устанавливает полный пакет SDK для работы на устройстве.
tools-testapps устанавливает инструменты тестирования устройства (например, отладки серверного экрана).
x11 устанавливает X-сервер.
x11-base устанавливает X-сервер с минимальной оболочкой.
x11-sato устанавливает X-сервер с оболочкой OpenedHand Sato.

12.4. Отключение автоматически добавляемых свойств

Иногда системе сборки OE требуются значения MACHINE_FEATURES или DISTRO_FEATURES для контроля добавленной функциональности, которую невозможно отключить. В таких случаях нужно добавлять запись дополнительного свойства в одну из указанных переменных, но это заставит разработчиков, у которых уже заданы эти переменные, добавлять новые свойства, чтобы сохранить общий уровень функциональности. Поэтому система сборки OE включает механизм автоматического отключения (backfill) добавленных свойств в имеющиеся конфигурации дистрибутива или машины. Список свойств, для которых это выполняется, можно увидеть в переменных DISTRO_FEATURES_BACKFILL и MACHINE_FEATURES_BACKFILL файла meta/conf/bitbake.conf file.

Поскольку свойства по умолчанию включаются во все конфигурации, разработчики, желающие отключить ненужные свойства, должны указать их в переменной DISTRO_FEATURES_BACKFILL_CONSIDERED или MACHINE_FEATURES_BACKFILL_CONSIDERED.

Ниже приведены два примера.

Свойство дистрибутива pulseaudio. Ранее поддержка PulseAudio включалась в Qt и GStreamer. Поэтому свойство добавляется автоматически через переменную DISTRO_FEATURES_BACKFILL и автоматически включается для всех дистрибутивов в файле meta/conf/bitbake.conf. Для отключения этого свойства без влияния на конфигурации других дистрибутивов, которым нужна поддержка PulseAudio, добавляется значение pulseaudio в переменную DISTRO_FEATURES_BACKFILL_CONSIDERED файла конфигурации дистрибутива. Добавление в эту переменную свойства, указанного также в DISTRO_FEATURES_BACKFILL, предотвратит добавление системой сборки этого свойства в DISTRO_FEATURES, т. е. к отключению в данном дистрибутиве.
Свойство машины rtc.Ранее поддержка часов RTC1была включена для всех целевых устройств, поэтому свойство автоматически добавлялось для всех машин через переменную MACHINE_FEATURES_BACKFILLв файле meta/conf/bitbake.conf file. Однако такие часы поддерживают не все устройства. Для таких устройств можно отключить поддержку этих часов с помощью переменной MACHINE_FEATURES_BACKFILL_CONSIDEREDв файле конфигурации машины .conf. Добавление свойства в переменную MACHINE_FEATURES_BACKFILLпредотвратит включение свойства в переменную MACHINE_FEATURES, т. е. поддержку RTC в данной машине.

1Real time clock – часы в реальном масштабе времени.

Продолжение

1Linux Standard Base.

2Дополнение частично введенных команд при нажатии клавиши Tab.

3Virtual Box Virtual Disk Image – образ виртуального диска Virtual Box.

4QEMU Copy On Write Version 2.

5Executable and Linkable Format – исполняемый и компонуемый формат.

6Node package manager – менеджер пакетов узла.

Глава 5. Структура каталога исходных кодов

5.1. Компоненты верхнего уровня

5.1.1. bitbake/

5.1.2. build/

5.1.3. documentation/

5.1.4. meta/

5.1.5. meta-poky/

5.1.6. meta-yocto-bsp/

5.1.7. meta-selftest/

5.1.8. meta-skeleton/

5.1.9. scripts/

5.1.9.1 oe-init-build-env

5.1.10. LICENSE, README и README.hardware

5.2. Каталог сборки build/

5.2.1. build/buildhistory

5.2.2. build/conf/local.conf

5.2.3. build/conf/bblayers.conf

5.2.4. build/conf/sanity_info

5.2.5. build/downloads/

5.2.6. build/sstate-cache/

5.2.7. build/tmp/

5.2.8. build/tmp/buildstats/

5.2.9. build/tmp/cache/

5.2.10. build/tmp/deploy/

5.2.11. build/tmp/deploy/deb/

5.2.12. build/tmp/deploy/rpm/

5.2.13. build/tmp/deploy/ipk/

5.2.14. build/tmp/deploy/licenses/

5.2.15. build/tmp/deploy/images/

5.2.16. build/tmp/deploy/sdk/

5.2.17. build/tmp/sstate-control/

5.2.18. build/tmp/sysroots-components/

5.2.19. build/tmp/sysroots/

5.2.20. build/tmp/stamps/

5.2.21. build/tmp/log/

5.2.22. build/tmp/work/

5.2.23. build/tmp/work/tunearch/recipename/version/

5.2.24. build/tmp/work-shared/

5.3. Метаданные – meta/

5.3.1. meta/classes/

5.3.2. meta/conf/

5.3.3. meta/conf/machine/

5.3.4. meta/conf/distro/

5.3.5. meta/conf/machine-sdk/

5.3.6. meta/files/

5.3.7. meta/lib/

5.3.8. meta/recipes-bsp/